PDP-10 locations
John
in place? I'd really like to actually SEE a PDP-10 in person some
time... are there any in the San Francisco area still?
Thanks
John
Eric Smith
There aren't any running PDP-10 systems in the SF area that are on
public display, and it's not clear that there are any running ones in
the area at all, other than a few XKL boxes that might get fired up
on rare occasions.
If you just want to see a non-running hunk of iron, there are several,
including a KL10 CPU from Tymnet in "Visible Storage" at the Computer
History Museum in Mountain View.
Gregg Townsend
> in place? I'd really like to actually SEE a PDP-10 in person some
> time... are there any in the San Francisco area still?
Didn't I see one or two at the Computer History Museum in Mountain View?
Non-operational, of course, and without peripherals.
-----------------------------------------------------------------------
Gregg Townsend Staff Scientist The University of Arizona
g...@cs.arizona.edu Computer Science Tucson, Arizona, USA
Eric Smith
> Didn't I see one or two at the Computer History Museum in Mountain View?
> Non-operational, of course, and without peripherals.
The closest they have to a complete CPU is a KL10 from a 1090 from
MCI Tymnet. They don't have the memory or peripherals. The machine
originally used an Ampex semiconductor memory box and a System Concepts
SA10 channel (bus/tag) interface. Joe Smith could probably give more
details of that machine if anyone wanted to know.
None of the museum's other PDP-10 CPUs are anywhere close to complete [*].
They only have the console bay of a KA10, and the front end processor
(PDP-11/40) bay of a 2060 (KL10). I suspect that in the mid-1980s,
before the collection moved to the west coast, it was not considered
worthwhile to save an entire PDP-10 CPU, as they certainly could have
done so had they so desired.
Eric
[*] They do have an XKL machine that is apparently complete and working,
but I'd call that a PDP-10 clone rather than a PDP-10. No disrespect
intended to the fine folks at XKL, but part of my personal definition of
a PDP-whatever computer is that it was made by DEC.
Rich Alderson
> [*] They do have an XKL machine that is apparently complete and working,
> but I'd call that a PDP-10 clone rather than a PDP-10. No disrespect
> intended to the fine folks at XKL, but part of my personal definition of
> a PDP-whatever computer is that it was made by DEC.
So the Harris and Intersil chips used by DEC in late hardware do not qualify as
PDP-8's?
MAXC, the Foonly systems, the Systems Concepts systems, and the XKL Toad-1 are
all PDP-10's. It's an instruction set architecture, not a manufacturer.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless
Eric Smith
> [*] They do have an XKL machine that is apparently complete and working,
> but I'd call that a PDP-10 clone rather than a PDP-10. No disrespect
> intended to the fine folks at XKL, but part of my personal definition of
> a PDP-whatever computer is that it was made by DEC.
Rich Alderson wrote:
> So the Harris and Intersil chips used by DEC in late hardware do not qualify
> as PDP-8's?
They do when they're part of a PDP-8 made by DEC, of which there were none.
The VT78 and DECmate were not marketed as PDP-8 systems.
Other than that, they're almost but not completely PDP-8 compatible.
> MAXC, the Foonly systems, the Systems Concepts systems, and the XKL Toad-1 are
> all PDP-10's. It's an instruction set architecture, not a manufacturer.
I disagree. DEC defined a PDP-10 as a piece of hardware that a customer
purchased from them, and wouldn't have taken kindly to anyone else selling
a computer as a "PDP-10". As far as I can recall, none of the clone makers
claimed that their machines actually were PDP-10s, but merely that they were
compatible.
glen herrmannsfeldt
(snip)
> I disagree. DEC defined a PDP-10 as a piece of hardware that a customer
> purchased from them, and wouldn't have taken kindly to anyone else selling
> a computer as a "PDP-10". As far as I can recall, none of the clone makers
> claimed that their machines actually were PDP-10s, but merely that they were
> compatible.
Unlike IBM, which tried to make the S/360 and S/370 architecture
as similar as possible across the line it seems to me that the different
PDP-10 models were significantly different. Between the KA-10, KI-10
and KL-10 there were many differences. If I remember it right,
even at the user level, the KA-10 used a different format for
double precision floating point. For S/360, IBM designed the extended
precision (quad precision) floating point format to be relatively
easy to emulate in software such that the same format could be used
on all models.
Were there clones that would directly run systems designed for
the KA-10, KI-10, or KL-10, without modification?
-- glen
Rich Alderson
> Eric Smith wrote:
> (snip)
>> I disagree. DEC defined a PDP-10 as a piece of hardware that a customer
>> purchased from them, and wouldn't have taken kindly to anyone else selling
>> a computer as a "PDP-10". As far as I can recall, none of the clone makers
>> claimed that their machines actually were PDP-10s, but merely that they were
>> compatible.
> Unlike IBM, which tried to make the S/360 and S/370 architecture as similar
> as possible across the line it seems to me that the different PDP-10 models
> were significantly different. Between the KA-10, KI-10 and KL-10 there were
> many differences. If I remember it right, even at the user level, the KA-10
> used a different format for double precision floating point. For S/360, IBM
> designed the extended precision (quad precision) floating point format to be
> relatively easy to emulate in software such that the same format could be
> used on all models.
KA-10 floating point was available on the KL-10 processor; I don't have a KI-10
processor manual to verify whether it was available there.
> Were there clones that would directly run systems designed for
> the KA-10, KI-10, or KL-10, without modification?
The Systems Concepts clones (SC-30M, SC-20 & SC-25, and SC-40) strove to be
bug-for-bug compatible with the KL-10 processor, according to Stewart Nelson
(the SC architect).
Eric Smith
> Unlike IBM, which tried to make the S/360 and S/370 architecture as similar
> as possible across the line it seems to me that the different PDP-10 models
> were significantly different. Between the KA-10, KI-10 and KL-10 there were
> many differences. If I remember it right, even at the user level, the KA-10
> used a different format for double precision floating point.
Rich Alderson wrote:
> KA-10 floating point was available on the KL-10 processor; I don't have
> a KI-10 processor manual to verify whether it was available there.
I think Glen is referring to the DFN, UFA, FADL, FSBL, FMPL, and FDVL
instructions. Those existed on the KA10 and KI10, but were not present
on the KS10 and usually not on the KL10 because the limited microcode
storage was better used for other purposes.
These are doucmented in the DECsystem-10 DECSYSTEM-20 Processor Reference
Manual, Fifth Edition (AA-H391A-TK) with June 1982 update (AA-H391A-T1)
on pages 2-28.6 through 2-32. Presumably they were covered in all earlier
editions of the Processor Reference Manual, but I haven't checked.
The control sequencers of both the KL10-PV ("Model B") and KS10 were
designed to be capable of addressing twice as much control store as
was actually present. Given how chronically short of space the KL10
control store was, I was very surprised that the 1095/2065 upgrade
(KL10-PW) didn't double the control store at the same time they
doubled the cache and TLB sizes.
Eric
Mark Crispin
> I think Glen is referring to the DFN, UFA, FADL, FSBL, FMPL, and FDVL
> instructions. Those existed on the KA10 and KI10, but were not present
> on the KS10 and usually not on the KL10 because the limited microcode
> storage was better used for other purposes.
However, the TOPS-20 monitor implemented these as MUUOs. The same with
the G-float instructions that didn't get into the microcode. However,
G-float was KL-only. Consequently even an XKL or KLH10 based system
implements them (actually, AFAICT KLH10 systems implement them in
microcode).
Very few KL or KS systems that did not properly execute a DFN, UFA, FxxL
instruction. Perhaps the ITS systems did not, but I doubt that given how
very much KA-biased ITS was.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
jmfb...@aol.com
Eric Smith <er...@brouhaha.com> wrote:
>glen herrmannsfeldt wrote:
>> Unlike IBM, which tried to make the S/360 and S/370 architecture as similar
>> as possible across the line it seems to me that the different PDP-10 models
>> were significantly different. Between the KA-10, KI-10 and KL-10 there
were
>> many differences. If I remember it right, even at the user level, the
KA-10
>> used a different format for double precision floating point.
>
>Rich Alderson wrote:
>> KA-10 floating point was available on the KL-10 processor; I don't have
>> a KI-10 processor manual to verify whether it was available there.
>
>I think Glen is referring to the DFN, UFA, FADL, FSBL, FMPL, and FDVL
>instructions. Those existed on the KA10 and KI10, but were not present
>on the KS10 and usually not on the KL10 because the limited microcode
>storage was better used for other purposes.
JMF wrote a KA emulator to do those instructions. It was shipped
as KASER.MAC and a customer could combine the rel with TOPS10.REL.
To wean customer code away from using KA-specific instructions,
he issued a warning message whenever one was encountered.
IIRC, you should be able to find this file on the Customer
Supported Tape in the monitor save set.
>
>These are doucmented in the DECsystem-10 DECSYSTEM-20 Processor Reference
>Manual, Fifth Edition (AA-H391A-TK) with June 1982 update (AA-H391A-T1)
>on pages 2-28.6 through 2-32. Presumably they were covered in all earlier
>editions of the Processor Reference Manual, but I haven't checked.
The difference between KI and KA instructions are very nicely set
out in the System Reference Card, DEC-10-XSRCA-B-D. The KI is in
blue.
<snip>
/BAH
Mark Crispin
> JMF wrote a KA emulator to do those instructions.
Wasn't that just a port of the code that Ralph Gorin wrote for TOPS-20?
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Mark Crispin
> On Tue, 4 Mar 2008, jmfb...@aol.com posted:
>> JMF wrote a KA emulator to do those instructions.
> Wasn't that just a port of the code that Ralph Gorin wrote for TOPS-20?
If it is Ralph's code, there is a comment:
ONLY CRETINS DIVIDE BY "SETZ"
There is a story behind that...
glen herrmannsfeldt
(snip)
> The difference between KI and KA instructions are very nicely set
> out in the System Reference Card, DEC-10-XSRCA-B-D. The KI is in
> blue.
I commented to Al Kossow about the Fortran manual using blue ink
(maybe for extensions to the standard) and that not getting into
the scanned manuals. (Some bits are being lost.)
I suppose for a small card one could use a color scanner and
save those bits.
-- glen
jmfb...@aol.com
Mark Crispin <M...@Washington.EDU> wrote:
>On Tue, 4 Mar 2008, jmfb...@aol.com posted:
>> JMF wrote a KA emulator to do those instructions.
>
>Wasn't that just a port of the code that Ralph Gorin wrote for TOPS-20?
Not that I'm aware of.
Just to clarify. The instruction set was extended (I forget who
wrote a post thinking that that the new architectures didn't
support the old instruction codes. With the KL, the KA floating
point instructions were trapped and software did the instruction.
A warning was issued so that customers could identify which
pieces of the programs they ran would need attention if
they didn't want to have KASER module in the monitor.
This is one way to ease the customers' software base from one
instruction to another.
/BAH
jmfb...@aol.com
Mark Crispin <M...@Washington.EDU> wrote:
>On Tue, 4 Mar 2008, Mark Crispin posted:
>> On Tue, 4 Mar 2008, jmfb...@aol.com posted:
>>> JMF wrote a KA emulator to do those instructions.
>> Wasn't that just a port of the code that Ralph Gorin wrote for TOPS-20?
>
>If it is Ralph's code, there is a comment:
> ONLY CRETINS DIVIDE BY "SETZ"
>
>There is a story behind that...
If JMF lifted Gorin's heiuristics, JMF would have still had to
rewrite the code. ACs didn't match; symbols were different, etc.
Why did the -20 need a KA FPoint emulator? FORTRAN?
/BAH
jmfb...@aol.com
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>jmfb...@aol.com wrote:
>
>(snip)
>
>> The difference between KI and KA instructions are very nicely set
>> out in the System Reference Card, DEC-10-XSRCA-B-D. The KI is in
>> blue.
>
>I commented to Al Kossow about the Fortran manual using blue ink
>(maybe for extensions to the standard) and that not getting into
>the scanned manuals. (Some bits are being lost.)
The blue doesn't get copied? Lots of information is lost with
that oversight.
>
>I suppose for a small card one could use a color scanner and
>save those bits.
I'd say that the FORTRAN manual would be more important..but
this opinion is for using it to code. I don't know if anybody
would have a need to know which pieces of the FORTRAN code
may not run under other contemporary compilers.
/BAH
Mark Crispin
> Just to clarify. The instruction set was extended (I forget who
> wrote a post thinking that that the new architectures didn't
> support the old instruction codes. With the KL, the KA floating
> point instructions were trapped and software did the instruction.
Yes. The KS microcode and later versions of the KL microcode didn't have
enough space to implement the KA FP instructions, so they trapped as
MUUOs.
TOPS-20 implemented these MUUOs to do what the old instructions did. The
same was true of the G-Float instructions that didn't make it into the KL
microcode.
> A warning was issued so that customers could identify which
> pieces of the programs they ran would need attention if
> they didn't want to have KASER module in the monitor.
TOPS-20 didn't do this. The instructions simply executed.
Mark Crispin
>> ONLY CRETINS DIVIDE BY "SETZ"
> rewrite the code. ACs didn't match; symbols were different, etc.
Actually, that part of TOPS-20 used the DEC standard conventions (T1-T4,
etc.) which I think that TOPS-10 also used. The difference was that,
unlike TOPS-10, TOPS-20 allowed modules to define their own AC conventions
rather than strictly following the standard conventions. IIRC, TOPS-10
rigorously converted all modules to use the standard, and did not allow
new modules to deviate.
Of course, JMF would have had to change how things were called, and in
studying his corresponding -10 and -20 code it seems that he went to some
effort to do things "the -20 way" on the -20 and "the -10 way" on the -10.
This is particularly obvious with some of his device drivers, including
those that he first wrote on the -20. He went to some trouble to convert
styles; still you see the same basic algorithms.
> Why did the -20 need a KA FPoint emulator? FORTRAN?
The same reason that TOPS-10 on the KL needed it. People had old programs
that used the KA FP instructions, including software for which the source
code was no longer available. Some of it was F40-compiled FORTRAN
programs; but there was also a fair number of other programs that used
them as well.
jmfb...@aol.com
<alpine.WNT.1.00.0...@Tomobiki-Cho.CAC.Washignton.EDU>,
Mark Crispin <M...@Washington.EDU> wrote:
>On Wed, 5 Mar 2008, jmfb...@aol.com posted:
>> Just to clarify. The instruction set was extended (I forget who
>> wrote a post thinking that that the new architectures didn't
>> support the old instruction codes. With the KL, the KA floating
>> point instructions were trapped and software did the instruction.
>
>Yes. The KS microcode and later versions of the KL microcode didn't have
>enough space to implement the KA FP instructions, so they trapped as
>MUUOs.
>
>TOPS-20 implemented these MUUOs to do what the old instructions did. The
>same was true of the G-Float instructions that didn't make it into the KL
>microcode.
>
>> A warning was issued so that customers could identify which
>> pieces of the programs they ran would need attention if
>> they didn't want to have KASER module in the monitor.
>
>TOPS-20 didn't do this. The instructions simply executed.
hmmm...Maybe it was the -10 side that IDed all of our code
that had KA FP instructions in the compilers and OTSes.
/BAH
jmfb...@aol.com
<alpine.WNT.1.00.0...@Tomobiki-Cho.CAC.Washignton.EDU>,
Mark Crispin <M...@Washington.EDU> wrote:
>On Wed, 5 Mar 2008, jmfb...@aol.com posted:
>>> If it is Ralph's code, there is a comment:
>>> ONLY CRETINS DIVIDE BY "SETZ"
>> If JMF lifted Gorin's heiuristics, JMF would have still had to
>> rewrite the code. ACs didn't match; symbols were different, etc.
>
>Actually, that part of TOPS-20 used the DEC standard conventions (T1-T4,
>etc.) which I think that TOPS-10 also used. The difference was that,
>unlike TOPS-10, TOPS-20 allowed modules to define their own AC conventions
>rather than strictly following the standard conventions. IIRC, TOPS-10
>rigorously converted all modules to use the standard, and did not allow
>new modules to deviate.
>
>Of course, JMF would have had to change how things were called, and in
>studying his corresponding -10 and -20 code it seems that he went to some
>effort to do things "the -20 way" on the -20 and "the -10 way" on the -10.
>This is particularly obvious with some of his device drivers, including
>those that he first wrote on the -20. He went to some trouble to convert
>styles; still you see the same basic algorithms.
You are confused. I don't remember JMF writing any device drivers.
That was always TW's balliwick. And, yes, that is the way my
guys did their code. The rule was to write code and patches using
the philosophy of the author.
>
>> Why did the -20 need a KA FPoint emulator? FORTRAN?
>
>The same reason that TOPS-10 on the KL needed it. People had old programs
>that used the KA FP instructions, including software for which the source
>code was no longer available. Some of it was F40-compiled FORTRAN
>programs; but there was also a fair number of other programs that used
>them as well.
I don't remember shipping code that used F40 by KL timeframe. -20
customers started out being new DEC customers. They shouldn't have
had any F40 code.
Anyway, as soon as a customer had IDed and corrected all the
KA-specific code, the monitor could be rebuilt without the
chunk of KA emulator code; that freed up some more memory
for user-mode code.
/BAH
Mark Crispin
> I don't remember JMF writing any device drivers.
> That was always TW's balliwick.
You're right; it was TW code that I was looking at the other day.
> Anyway, as soon as a customer had IDed and corrected all the
> KA-specific code, the monitor could be rebuilt without the
> chunk of KA emulator code; that freed up some more memory
> for user-mode code.
Considering how small the MUUO code in question was, it would be silly to
remove it. It would be especially silly on TOPS-20, since its MUUO code
is swappable.
There were many other example of fat in the TOPS-10 monitor which could be
trimmed to better effect.
Rich Alderson
> On Wed, 5 Mar 2008, jmfb...@aol.com posted:
>> If JMF lifted Gorin's heiuristics, JMF would have still had to
>> rewrite the code. ACs didn't match; symbols were different, etc.
> Actually, that part of TOPS-20 used the DEC standard conventions (T1-T4,
> etc.) which I think that TOPS-10 also used. The difference was that,
> unlike TOPS-10, TOPS-20 allowed modules to define their own AC conventions
> rather than strictly following the standard conventions. IIRC, TOPS-10
> rigorously converted all modules to use the standard, and did not allow
> new modules to deviate.
The *naming* between Tops-10 and TOPS-20 is similar, but the assignments are
different. In the Tops-10 monitor, P (the stack pointer) is AC 1, and the
temp registers T1-T4 are ACs 2-5; in the TOPS-20 monitor, P is AC 17 and
T1-T4 are ACs 1-4 (which is the standard for user programs on both systems).
When Ralph ported Tops-10 to the Toad-1, he changed the AC assignments to
match the TOPS-20 standard, so that he could use TOPS-20 .REL files without
recompiling (for things like SCSI disks).
Before anyone asks, it was never a product, as our one Tops-10 customer lost
funding. It had no networking code, so only the console was available. I'm
given to understand that no one at XKL has Tops-10 any longer.
jmfb...@aol.com
Mark Crispin <m...@Washington.EDU> wrote:
>On Thu, 6 Mar 2008, jmfb...@aol.com posted:
>> I don't remember JMF writing any device drivers.
>> That was always TW's balliwick.
>
>You're right; it was TW code that I was looking at the other day.
>
>> Anyway, as soon as a customer had IDed and corrected all the
>> KA-specific code, the monitor could be rebuilt without the
>> chunk of KA emulator code; that freed up some more memory
>> for user-mode code.
>
>Considering how small the MUUO code in question was, it would be silly to
>remove it. It would be especially silly on TOPS-20, since its MUUO code
>is swappable.
Every little bit counts. This was also the style of building
a -10 monitor. Why should we change what worked?
>
>There were many other example of fat in the TOPS-10 monitor which could be
>trimmed to better effect.
We didn't get paid to trim fat. Any improvements done had to be
done on the back of a hardware project. This is something that
you don't seem to understand about what kinds of work people
at DEC did.
The biggest fat trimming work coincided with SMP. JMF and TW
did as much as they could do without jeopardizing the project.
/BAH
jmfb...@aol.com
Rich Alderson <ne...@alderson.users.panix.com> wrote:
>Mark Crispin <M...@Washington.EDU> writes:
>
>> On Wed, 5 Mar 2008, jmfb...@aol.com posted:
>
>>> If JMF lifted Gorin's heiuristics, JMF would have still had to
>>> rewrite the code. ACs didn't match; symbols were different, etc.
>
>> Actually, that part of TOPS-20 used the DEC standard conventions (T1-T4,
>> etc.) which I think that TOPS-10 also used. The difference was that,
>> unlike TOPS-10, TOPS-20 allowed modules to define their own AC conventions
>> rather than strictly following the standard conventions. IIRC, TOPS-10
>> rigorously converted all modules to use the standard, and did not allow
>> new modules to deviate.
>
>The *naming* between Tops-10 and TOPS-20 is similar, but the assignments are
>different. In the Tops-10 monitor, P (the stack pointer) is AC 1, and the
>temp registers T1-T4 are ACs 2-5; in the TOPS-20 monitor, P is AC 17 and
>T1-T4 are ACs 1-4 (which is the standard for user programs on both systems).
>
>When Ralph ported Tops-10 to the Toad-1, he changed the AC assignments to
>match the TOPS-20 standard, so that he could use TOPS-20 .REL files without
>recompiling (for things like SCSI disks).
That was brave of him. Do you know what kinds of problems he found?
>
>Before anyone asks, it was never a product, as our one Tops-10 customer lost
>funding. It had no networking code, so only the console was available. I'm
>given to understand that no one at XKL has Tops-10 any longer.
Darn. It would have been nice to see how it did on that gear.
/BAH
Mark Crispin
> Every little bit counts. This was also the style of building
> a -10 monitor. Why should we change what worked?
>
> We didn't get paid to trim fat. Any improvements done had to be
> done on the back of a hardware project. This is something that
> you don't seem to understand about what kinds of work people
> at DEC did.
These two statement contradict each other, and make sense only if you
assume a "penny-wise/pound-foolish" mentality on the part of DEC.
I found a copy of KASER.MAC on trailing-edge. It *is* Ralph's code. Even
you should be able to look at it and recognize how small it is.
Given numerous old programs (including DECUS binaries) that used KA FP, it
was a silly waste of effort to make that code removable. In most builds,
it would not reduce the size of the monitor by even a single page. It was
a complete waste of resources, given that you "didn't get paid to trim
fat".
What's more, as late as 7.02 (my 7.03 sources are not online, but I have
little doubt that there is any difference), TOPS-10 had identifiable fat
(mostly added in 5 and 6 series in the early-to-mid 1970s) that was much
larger and could be removed/rewritten without causing any end-user impact.
In at least one case, it would make the system run faster.
Rich Alderson
> In article <mddablb...@panix5.panix.com>,
> Rich Alderson <ne...@alderson.users.panix.com> wrote:
>> When Ralph ported Tops-10 to the Toad-1, he changed the AC assignments to
>> match the TOPS-20 standard, so that he could use TOPS-20 .REL files without
>> recompiling (for things like SCSI disks).
> That was brave of him. Do you know what kinds of problems he found?
I don't recall him making any particular comments on difficulties, and Ralph is
famous for the quality of his grumpy commentaries.
>> Before anyone asks, it was never a product, as our one Tops-10 customer lost
>> funding. It had no networking code, so only the console was available. I'm
>> given to understand that no one at XKL has Tops-10 any longer.
> Darn. It would have been nice to see how it did on that gear.
I agree. I didn't have any 10 experience to draw on when he did it; with more
than 4 years here it would be much more informative to see it now.
Ah, well.
jmfb...@aol.com
>> Every little bit counts. This was also the style of building
>> a -10 monitor. Why should we change what worked?
>> [snip]
>>
>> We didn't get paid to trim fat. Any improvements done had to be
>> done on the back of a hardware project. This is something that
>> you don't seem to understand about what kinds of work people
>> at DEC did.
>
>These two statement contradict each other, and make sense only if you
>assume a "penny-wise/pound-foolish" mentality on the part of DEC.
That is because you are thinking like a customer.
>
>I found a copy of KASER.MAC on trailing-edge. It *is* Ralph's code.
Or Jim's. People used other people's code. It was a waste of
time to debug the same thing twice.
> Even
>you should be able to look at it and recognize how small it is.
>
>Given numerous old programs (including DECUS binaries) that used KA FP, it
>was a silly waste of effort to make that code removable. In most builds,
>it would not reduce the size of the monitor by even a single page. It was
>a complete waste of resources, given that you "didn't get paid to trim
>fat".
>
>What's more, as late as 7.02 (my 7.03 sources are not online, but I have
>little doubt that there is any difference), TOPS-10 had identifiable fat
>(mostly added in 5 and 6 series in the early-to-mid 1970s) that was much
>larger and could be removed/rewritten without causing any end-user impact.
>In at least one case, it would make the system run faster.
Mark, a goal was to wean people from writing KA-specific code.
The module gave a warning which was prepended with a %. Removing
the module from the monitor would generate a fatal error prepended
with a ?. Think about batch jobs.
/BAH
jmfb...@aol.com
Rich Alderson <ne...@alderson.users.panix.com> wrote:
>jmfb...@aol.com writes:
>
>> In article <mddablb...@panix5.panix.com>,
>> Rich Alderson <ne...@alderson.users.panix.com> wrote:
>
>>> When Ralph ported Tops-10 to the Toad-1, he changed the AC assignments to
>>> match the TOPS-20 standard, so that he could use TOPS-20 .REL files
without
>>> recompiling (for things like SCSI disks).
>
>> That was brave of him. Do you know what kinds of problems he found?
>
>difficulties, and Ralph is
>famous for the quality of his grumpy commentaries.
<GRIN> JMF and TW talked about this. They were not comfortable
changing the values, especially with lots of customer sites
who did their own. They also had a feeling that there had
to be some code somewhere in the deep dark guts of the monitor
that depended on F being 0. hmmm..now F sounds like the wrong
word to use. It was safer to keep the assignments rather than
change them. I was curious if their bad feeling was true.
>
>>> Before anyone asks, it was never a product, as our one Tops-10 customer
lost
>>> funding. It had no networking code, so only the console was available.
I'm
>>> given to understand that no one at XKL has Tops-10 any longer.
>
>> Darn. It would have been nice to see how it did on that gear.
>
>I agree. I didn't have any 10 experience to draw on when he did it; with
more
>than 4 years here it would be much more informative to see it now.
>
>Ah, well.
Well, a TOPS-10 system isn't interesting with only a CTY hanging
off it. It would have neat to see if any race conditions showed
up because of the increased speed of the CPU. Then the next
interesting configuration would have two CPUs. I suppose the
HSC approach to disk I/O could have been used for the I/O on
your gear.
The new bottlenecks were always surprising until hindsight occurred.
/BAH
Morten Reistad
<jmfb...@aol.com> wrote:
>In article <alpine.OSX.1.00.0...@pangtzu.panda.com>,
> Mark Crispin <m...@Washington.EDU> wrote:
>>On Thu, 6 Mar 2008, jmfb...@aol.com posted:
>>
>>There were many other example of fat in the TOPS-10 monitor which could be
>>trimmed to better effect.
>
>We didn't get paid to trim fat. Any improvements done had to be
>done on the back of a hardware project. This is something that
>you don't seem to understand about what kinds of work people
>at DEC did.
We understand that perfectly well.
I tought I was done with this polemic, but you don't seem to understand
the customers like us, so I make one last try.
The policy of DEC, Digital, and whoever took over was to sell iron.
The brass at DEC/DIGITAL/etc didn't see how important software was.
All DEC/DIGITAL employees had to back up the line of selling hardware.
This has been made abundantly clear here, and Barb has been important
in telling this inside story. It was largely unknown to people like
myself.
However, the customers didn't buy hardware. They bought the software,
and just needed hardware to run it on. This was blatantly evident
by around 1975, or earlier. I was there to observe from 1978. I saw this
at once, the software was the interesting bit. In the short term, this
is not a big difference. DEC got their iron sold, and the customer could
run the software they wanted. But in a long term, there is a fatal
squeeze that will break any company, usually in a matter of months.
Many emplyees saw this squeeze, and did the best they could for the
company. Countless brilliant engineers compensated for the shortfall
of the brass. TW, JMF, and others were dealing with this every day, and
tried to solve an insolvable mess as best they could. This cushioned the
customers from the DEC brass for a decade or two.
>The biggest fat trimming work coincided with SMP. JMF and TW
>did as much as they could do without jeopardizing the project.
Now I understand the SMP importance. It wasn't primarily the SMP, that
is just postponing the inevitable, but the opportunity and funding to
do What Is Right, so they customers got what they needed. A breathing
hole to actually deal with the software that customers needed. Taking
that opportinity and making the most of it speaks to the credit of
the engineers that took it.
But the DEC critique from people like us is just as sharp. It is a
crucifying damnation of the top, and that includes Ken Olsen. This
all started there. Middle managemet took it up.
Now, a normal company with such a discrepancy would be dead in a few
years. But DEC kept it up for decades, due to countelss acts of civil
disobedience from the engineers.
And DEC very nearly failed as a hardware company too. The Venus was
way overdue when it came. But let us leave that.
To specify what I mean, let us test a different scenario.
What if DEC, in late 1981,or early 1982 had said that the PDP10
had no future, but that they would do a couple of last-minute upgrades,
a clock push, a microcode rewrite in a larger store, and a much larger
cache, and a way to cluster the PDP10s. It would have bought some time.
Simultaneuously, port tops20 (and tops10, even) to the VAX. OK; it is
32 bits, different page sizes, and new drivers. But it would have been
doable in a few years with the right tools. Offer MACRO and binary translation
support. And show that all the focus is on the Vax. Let the new machine
be network/clusterable with the old one.
And show off a "beta tops20" on the intro. It does not have
to run much more than the exec and a few games.
This is what I believe DEC would have done if they understood the
software importance.
-- mrr
Mark Crispin
>> These two statement contradict each other, and make sense only if you
>> assume a "penny-wise/pound-foolish" mentality on the part of DEC.
> That is because you are thinking like a customer.
Customers are always right. DEC's failure to understand this is a direct
cause of DEC's demise.
>> I found a copy of KASER.MAC on trailing-edge. It *is* Ralph's code.
> Or Jim's. People used other people's code. It was a waste of
> time to debug the same thing twice.
JMF copied Ralph's code, even preserving Ralph's famous comment
ONLY CRETINS DIVIDE BY "SETZ"
KASER.MAC is dated 10 SEP 85.
I will have to review my copy of the 1984 36 Bit Pioneer's Roundtable
tape, but either JMF or Pete Hurley discussed that code and comment, and
talked about what happened when some cretin did divide by SETZ.
> Mark, a goal was to wean people from writing KA-specific code.
Whose goal? Where was it stated?
In TOPS-20, the KA FP instruction support is part of UUO service with no
way to disable it. The only reason why those instructions were ever
removed was there at all is because the model B KL microcode ran out of
room. It was in earlier versions of KL microcode.
Nor was there any effort to remove far more obvious warts, such as
JSA/JRA, that were widely understood to be a bad idea even in the 1960s.
It is far more likely that by the time this was done, there were maybe 10
TOPS-10 customers left and none of them cared. Had they tried it in
TOPS-20, the pitchforks, pikes, tar, and feathers would be out in full
force.
Nobody wrote programs using KA FP instructions by that time; and as you
well know he overwhelming use of FP instructions of any kind was in
generated code by compilers. The single greatest source of KA FP
instruction executions was from old F40-compiled binaries, and the notion
that these could be "weaned" or "fixed" is ludicrous.
> The module gave a warning which was prepended with a %.
I see no sign of that in KASER.MAC. It also would have been idiotic to do
that unless it had a count and only issued it once per job. FORTRAN
number crunchers do a lot of floating point.
> Removing
> the module from the monitor would generate a fatal error prepended
> with a ?. Think about batch jobs.
That's because the KA FP instructions execute as an MUUO on the KS and
model B KLs. That has nothing to do with KASER.
jmfb...@aol.com
Morten Reistad <fi...@last.name> wrote:
>In article <fqr9h2$8qk...@s863.apx1.sbo.ma.dialup.rcn.com>,
> <jmfb...@aol.com> wrote:
>>In article <alpine.OSX.1.00.0...@pangtzu.panda.com>,
>> Mark Crispin <m...@Washington.EDU> wrote:
>>>On Thu, 6 Mar 2008, jmfb...@aol.com posted:
>
>>>
>>>There were many other example of fat in the TOPS-10 monitor which could be
>>>trimmed to better effect.
>>
>>We didn't get paid to trim fat. Any improvements done had to be
>>done on the back of a hardware project. This is something that
>>you don't seem to understand about what kinds of work people
>>at DEC did.
>
>We understand that perfectly well.
Some do. And then some forget.
>
>I tought I was done with this polemic, but you don't seem to understand
>the customers like us, so I make one last try.
I do understand. However, berating my guys because they didn't do
EVERYthing perfectly is not acceptable.
>
>The policy of DEC, Digital, and whoever took over was to sell iron.
>The brass at DEC/DIGITAL/etc didn't see how important software was.
>All DEC/DIGITAL employees had to back up the line of selling hardware.
>This has been made abundantly clear here, and Barb has been important
>in telling this inside story. It was largely unknown to people like
>myself.
>
>However, the customers didn't buy hardware. They bought the software,
>and just needed hardware to run it on. This was blatantly evident
>by around 1975, or earlier.
This was not clear at that time.
>I was there to observe from 1978. I saw this
>at once, the software was the interesting bit. In the short term, this
>is not a big difference. DEC got their iron sold, and the customer could
>run the software they wanted. But in a long term, there is a fatal
>squeeze that will break any company, usually in a matter of months.
>
>Many emplyees saw this squeeze, and did the best they could for the
>company. Countless brilliant engineers compensated for the shortfall
>of the brass. TW, JMF, and others were dealing with this every day,
A lot of others. I have no idea how the minis' people did this work.
>and
>tried to solve an insolvable mess as best they could. This cushioned the
>customers from the DEC brass for a decade or two.
>
>>The biggest fat trimming work coincided with SMP. JMF and TW
>>did as much as they could do without jeopardizing the project.
>
>Now I understand the SMP importance. It wasn't primarily the SMP, that
>is just postponing the inevitable, but the opportunity and funding to
>do What Is Right, so they customers got what they needed. A breathing
>hole to actually deal with the software that customers needed. Taking
>that opportinity and making the most of it speaks to the credit of
>the engineers that took it.
If you only how hard it was to convince the steering committee
that selling multi CPUs to the same system site without the
customer having to double administration costs. As it was, DEC
cancelled SMP when they announced at Spring DECUS that 6.04 was
the last TOPS-10 monitor and that 6.04 would not include SMP.
>
>But the DEC critique from people like us is just as sharp. It is a
>crucifying damnation of the top, and that includes Ken Olsen. This
>all started there. Middle managemet took it up.
I understand and it should be sharp. But don't blame my guys for
the anal retention of Bell and Co.
>
>Now, a normal company with such a discrepancy would be dead in a few
>years. But DEC kept it up for decades, due to countelss acts of civil
>disobedience from the engineers.
This is why DEC was loved. When those engineers were removed from
customer contact, Digital happened and then died. DEC was just
beginning to come back with the Alpha, the first decent architecture
since the PDPs (w.r.t. software running it).
>
>And DEC very nearly failed as a hardware company too. The Venus was
>way overdue when it came. But let us leave that.
I still do not understand how hardware groups managed to not work.
>
>To specify what I mean, let us test a different scenario.
>
>What if DEC, in late 1981,or early 1982 had said that the PDP10
>had no future, but that they would do a couple of last-minute upgrades,
>a clock push, a microcode rewrite in a larger store, and a much larger
>cache, and a way to cluster the PDP10s. It would have bought some time.
We did that with SMP in 1980. After Jupiter was, thankfully, removed
from the budget, there was another proposal with specs to do just
this only in a desktop sized box. With ethernet tons of iron wasn't
required anymore.
>
>Simultaneuously, port tops20 (and tops10, even) to the VAX. OK; it is
>32 bits, different page sizes, and new drivers. But it would have been
>doable in a few years with the right tools.
We were doing that. My proposal was to do an emulation just like
Bob Supnik has now done. That would have taken care of any
customers' data and computing processing that had to be run on
a PDP-10.
> Offer MACRO and binary translation
>support. And show that all the focus is on the Vax. Let the new machine
>be network/clusterable with the old one.
This project had a name: migration. Oodles of monies was spent on that.
>And show off a "beta tops20" on the intro. It does not have
>to run much more than the exec and a few games.
>
>This is what I believe DEC would have done if they understood the
>software importance.
Were you watching when the migration thingie happened?
/BAH
jmfb...@aol.com
Mark Crispin <m...@Washington.EDU> wrote:
>On Sat, 8 Mar 2008, jmfb...@aol.com posted:
>>> These two statement contradict each other, and make sense only if you
>>> assume a "penny-wise/pound-foolish" mentality on the part of DEC.
>> That is because you are thinking like a customer.
>
>Customers are always right.
No, they are not.
> DEC's failure to understand this is a direct
>cause of DEC's demise.
Each customer, rightly, has only his interests in mind. The job
of the monitor developers was to deliver a software package
that would satify them all. What we couldn't write for them, we
tried to provide enough tools so that they could hire somebody
to do their site-specific work.
>
>>> I found a copy of KASER.MAC on trailing-edge. It *is* Ralph's code.
>> Or Jim's. People used other people's code. It was a waste of
>> time to debug the same thing twice.
>
>JMF copied Ralph's code, even preserving Ralph's famous comment
> ONLY CRETINS DIVIDE BY "SETZ"
Or they collaborated. I don't remember. It was not a sin to
use other people's code in our shop. I wish you would understand
that, too. It was stupid for us to not use other people's code if the
code has been debugged and proven to work.
>
>KASER.MAC is dated 10 SEP 85.
The dates don't count. The date of the MCO implementing does.
>
>I will have to review my copy of the 1984 36 Bit Pioneer's Roundtable
>tape, but either JMF or Pete Hurley discussed that code and comment, and
>talked about what happened when some cretin did divide by SETZ.
>
>> Mark, a goal was to wean people from writing KA-specific code.
>
>Whose goal? Where was it stated?
When the KA had stopped being supported.
>
>In TOPS-20, the KA FP instruction support is part of UUO service with no
>way to disable it. The only reason why those instructions were ever
>removed was there at all is because the model B KL microcode ran out of
>room. It was in earlier versions of KL microcode.
>
>Nor was there any effort to remove far more obvious warts, such as
>JSA/JRA, that were widely understood to be a bad idea even in the 1960s.
>
>It is far more likely that by the time this was done, there were maybe 10
>TOPS-10 customers left and none of them cared.
You don't have any bloody idea. There were lots of -10 customers.
Go read any SPR bulliten that came out. And those were just the
-10 customers who wrote about a problem.
>Had they tried it in
>TOPS-20, the pitchforks, pikes, tar, and feathers would be out in full
>force.
>
>Nobody wrote programs using KA FP instructions by that time; and as you
>well know he overwhelming use of FP instructions of any kind was in
>generated code by compilers. The single greatest source of KA FP
>instruction executions was from old F40-compiled binaries, and the notion
>that these could be "weaned" or "fixed" is ludicrous.
I don't remember any F40 binaries running. When FOROTS V6 came
out, we found out how many customers were tied to V5. There were
none tied to F40.
I'm pooped. I'm also toying with writing a disclaimer which I'll
reply to any of your posts from this day forward. Most of what
you post is dinigrating to my guys. Just like Gordon Bell, you
blame them for all the world's troubles. If it weren't for my
guys and others (see Morten's) post, you would have never seen
a PDP-10 instruction set.
/BAH
Mark Crispin
> DEC was just
> beginning to come back with the Alpha, the first decent architecture
> since the PDPs (w.r.t. software running it).
To paraphrase Mark Twain:
It seems to me that it is far from right for you to
deliver opinions on Alpha and its software without
having used it. It would have been much more decorous
to keep silent and let persons talk who have used Alpha
and its software.
OSF/1, the variant of UNIX for Alpha, has some defects...
The first and most glaring defect of OSF/1 is that it existed in the first
place. The common joke was that OSF stood for "Opposed to SUN Forever" as
it was a fork that rejected SVR4 (and, for no apparent reason, BSD) and
its licensing. OSF had lined up a plethora of Big Vendors for their
misleadingly-named "open software" but in the end DEC was the only one to
do more than play with OSF/1.
The OSF itself committed harakiri in 1994.
Unlike Linux, which was a similar fork, there was no apparent benefit to
the user community for the OSF/1 fork. OSF/1 was a careful effort to copy
SVR4 (including all of its mistakes), thoroughly reject everything done
right in BSD, and create completely new mistakes. And it most certainly
was not "open software"; it was quite proprietary.
And did it make mistakes.
OSF/1 stands as a shining example of how NOT to use Mach as a base for a
UNIX platform. NEXTSTEP and Mac OS X did a much better job.
The less said about the C compiler on OSF/1 the better. I fought multiple
battles with that compiler. DEC refused to belive that their precious
compiler generated bad until I gave them small sample programs that proved
it. Stupid bugs, such as post-increment of a short adding 2 instead of 1.
Unlike porting to Linux, which for the most part "just works" with little
or no modification, porting to OSF/1 was at least as difficult as porting
between BSD and SVR4. There were strange differences in OSF/1 which had
no apparent reason to exist.
I still have a ball-peen hammer ready to crash on the cranium of whatever
cretin at Digital decided that OSF/1 should no longer have flock() as a
separate system call from fcntl() locking, and instead make flock() a C
library routine that uses fcntl() locking. I found out about that change
when suddenly problem reports of file corruption started flowing in.
Then there were the operating system bugs. One of OSF/1's charming quirks
was that it didn't seem to be able to do random access I/O properly unless
you did it with an entire disk block. It would usually do the right
thing; but every so often it would zero out the part of the block that you
didn't update. This led to lots of fun and laughter.
Then there was AdvFS on OSF/1. System managers loved its features. That
is, until AdvFS corrupted multiple TB of filesystems, necessitating a full
filesystem restore from backup. UW ended up with an emergency project to
replace all of our OSF/1 servers with Linux. We never looked back.
In short, OSF/1 was unreliable. Worse, it was non-robust. When it
screwed up, it screwed up massively.
In an effort to escape the increasingly bad reputation associated with the
name, Digital renamed OSF/1. First they called it Digital UNIX. That
helped to sink the Digital name even further.
Then, in a final burst of desperation, they called it Tru64 (this may have
happened after Compaq bought Digital, or HP bought Compaq) in a futile
attempt to ride the 64-bit bandwagon. It didn't work. No matter what
name, the stench lingered on.
Tru64 is on life support today. HP apparently intends a maintenance
release this year, but otherwise it's been in a coma for the past several
years.
Good riddance.
Mark Crispin
> No, they are not.
Yes we are.
Not only are customers always right, but customers define what constitutes
"right". They also decide whether companies live or die.
> Each customer, rightly, has only his interests in mind. The job
> of the monitor developers was to deliver a software package
> that would satify them all.
However, as you have made abundantly clear, DEC had the attitude that
their job was to satisfy themselves; they falsely believed that they knew
better than their customers.
Apple and Sony are examples of companies today that have the same
attitude. Like DEC, both are masters of design. As long as they make
compelling products, they get away with their arrogant attitudes.
However, the moment they falter, the customers turn on them. Viciously.
Such companies are great for short-term investments to make a lot of money
quickly. But you don't want to keep long-term retirement assets there.
Pity the poor fools who rode Digital all the way down.
>> JMF copied Ralph's code, even preserving Ralph's famous comment
>> ONLY CRETINS DIVIDE BY "SETZ"
> Or they collaborated. I don't remember.
I don't recall Ralph working with JMF, and I worked for Ralph during the
time when he must have written the KA FP compatibility code.
> It was not a sin to
> use other people's code in our shop. I wish you would understand
> that, too. It was stupid for us to not use other people's code if the
> code has been debugged and proven to work.
Nobody says otherwise. The point was simply that JMF did not create that
code. He reused code that was in TOPS-20.
>> KASER.MAC is dated 10 SEP 85.
> The dates don't count. The date of the MCO implementing does.
KASER.MAC has an MCO history...which is completely empty.
>>> Mark, a goal was to wean people from writing KA-specific code.
>> Whose goal? Where was it stated?
> When the KA had stopped being supported.
That doesn't answer the questions.
Who (names, please) established the "goal" to "wean people from writing
KA-specific code"?
Did the "goal" include "weaning" people from running KA-specific binaries?
Where was the "goal" published?
How does the "goal" reconcile with the considerable efforts to maintain
compatibility that occurred concurrently?
Why, given the "goal", did TOPS-20 simply implement the offending
instructions as MUUOs without error reporting?
> You don't have any bloody idea. There were lots of -10 customers.
> Go read any SPR bulliten that came out. And those were just the
> -10 customers who wrote about a problem.
You don't want to go there, Barb. I have physical evidence: a complete
set of the last several years of LCG SPR bulletins.
I can tell you when they merged the -10 bulletin with the -20 one, because
there weren't enough -10 customers/SPRs any more, and when they stopped
issuing a printed bulletin and went to microfiche only.
By 1985, the -10 community was dead. The -10 customers who hadn't
upgraded to the -20 years earlier went to VMS.
> I don't remember any F40 binaries running.
Perhaps not in the cloisters on Marlboro. The real world was something
quite different.
> When FOROTS V6 came
> out, we found out how many customers were tied to V5. There were
> none tied to F40.
IIRC, F40 did not use a FOROTS hiseg at all; it would not have worked on
the PDP-6. The first that I remember hearing about FOROTS was when
FORTRAN-10 was installed.
I know for a fact that there were F40 compiled .SAV files used by
professors for many years after the source was long gone, or on punch
cards that were damaged (water, termites, rodents) and no longer readable.
> If it weren't for my
> guys and others (see Morten's) post, you would have never seen
> a PDP-10 instruction set.
Bullshit. Neither JMF nor TW were around at that time in 1964 when your
enemy Gordon Bell, along with Alan Kotok, gave the world the PDP-6
instruction set. It was Bell, Kotok, and Bob Clements who gave the world
the KA10. Ray Tomlinson and Dan Murphy gave the world Tenex, which later
became TOPS-20.
Pat Farrell
> However, the customers didn't buy hardware. They bought the software,
> and just needed hardware to run it on. This was blatantly evident
> by around 1975, or earlier.
I'll agree but change the words a bit. Customers didn't buy hardware or
software. They bought solutions to business problems.
The business problems varies, teaching fortran to 500 engineering
students, or tracking sales of cigarettes in response to ad campaigns, but
it was the result that was important not the hardware or software.
The combination of TOPS-10 on KIs was a great solution to many problems.
TOPS-20 on KLs (one we stopped screwing with idiotic configurations like a
2040 and move to a B model with lots o cache and memory, solved lots of
real problems.
The problems presented grow over time. In scale in several dimensions:
more users, more complex problems, bigger problems, etc.
Mark Crispin
> On Sat, 08 Mar 2008 13:43:45 +0100, Morten Reistad wrote:
>> However, the customers didn't buy hardware. They bought the software,
>> and just needed hardware to run it on. This was blatantly evident
>> by around 1975, or earlier.
> I'll agree but change the words a bit. Customers didn't buy hardware or
> software. They bought solutions to business problems.
Hmm. I think that that this overlooks an important segment of the market:
customers who bought platforms that would support their pre-existing
solutions to their business problems. That is, the customer had the
solution, but needed to expand the number of engines that executed the
solution.
There was quite a debate in the 1980s between those that favored fewer
large powerful engines (sometimes creating a monolithic engine from
existing smaller engines) and those who favored loosely-coupled clusters
of many, smaller, less powerful engines. The debate was eventually won by
the latter due to economic factors; the Great Monoliths fell to the Killer
Micros.
> The combination of TOPS-10 on KIs was a great solution to many problems.
The KI10 was the perfect TOPS-10 engine. It was an significant upgrade
from the KA10, even more than the modest processor speed improvement would
indicate, because its memory map made it possible to get rid of The Big
BLT.
I suspect that most TOPS-10 customers would have been happy with a
lower cost (and less power-hungry) KI10-class CPU instead of a KL10.
The KI10 was not particularly satisfactory for ITS and Tenex because its
memory map simply was not up to the requirements of a pager; both ITS and
Tenex had custom paging hardware added to their KA10 systems. Tenex was
ported to the the KI10 anyway, but KI10 Tenex was never particularly
impressive. Most of the KI10 Tenex systems were dual-CPU systems to get
any sort of reasonable performance.
Pat Farrell
> On Mon, 10 Mar 2008, Pat Farrell posted:
>> software. They bought solutions to business problems.
> large powerful engines
Not too long into the 80s, as DEC stopped being a player :-)
> The debate was eventually won by
> the latter due to economic factors; the Great Monoliths fell to the Killer
> Micros.
I'm not sure I agree. Micros really could not do it, even networked with
Netware. It really took the dot.com bubble to come up with clear winners.
The current buzz about cloud computing (and Google's architecture) show
that big systems still deliver solutions to real world problems.
Rich Alderson
> In article <mddtzji...@panix5.panix.com>,
> Rich Alderson <ne...@alderson.users.panix.com> wrote:
>> jmfb...@aol.com writes:
>>> In article <mddablb...@panix5.panix.com>,
>>> Rich Alderson <ne...@alderson.users.panix.com> wrote:
>>>> When Ralph ported Tops-10 to the Toad-1, he changed the AC assignments to
>>>> match the TOPS-20 standard, so that he could use TOPS-20 .REL files
>>>> without recompiling (for things like SCSI disks).
[snip]
> <GRIN> JMF and TW talked about this. They were not comfortable
> changing the values, especially with lots of customer sites
> who did their own. They also had a feeling that there had
> to be some code somewhere in the deep dark guts of the monitor
> that depended on F being 0. hmmm..now F sounds like the wrong
> word to use. It was safer to keep the assignments rather than
> change them. I was curious if their bad feeling was true.
F is 0 in the TOPS-20 standards, too, so it didn't have to change, and had no
effect on the project.
John
discussion on how DEC went wrong before going even further into
chatter about various design decisions and page after page of "No they
didn't do that" "Yes they did, I was working there" "No they didn't,
I'm Gordon Bell"?
Not that I'm complaining...
Werner
I second that
Werner Dahn
glen herrmannsfeldt
(big snip)
> Now that I'm through pontificating,
> I'm going to put some more time into getting my TOPS-20/KLH-10
> running, which reminds me, does anyone have a useful pointer
> (along the lines of, "go RTFM, *this* FM at some URL")
This reminds me, there are people on the Hercules project,
an emulator of IBM mainframes, working on S/380.
That is, an emulation of a system that never existed,
but could have, somewhere between S/370 and ESA/390.
I know people have suggested here how the PDP-10 architecture
could have been extended and kept viable. Is there interest
in an emulator for an extended PDP-10, maybe with 36 bit
addressing? Does enough OS source exist to generate a
system to run on an extended PDP-10? Maybe port Linux
to a 36 bit system?
-- glen
Pat Farrell
> Why does every discussion on this newsgroup descend into a repetitive
> discussion on how DEC went wrong before going even further into
> chatter about various design decisions and page after page of
perhaps there is little else to talk about? The whole why Dec is dead is
really way OT for locations of breathing or dead PDP-10s, foonleys, etc.
I know that in the olden days of the dot.com bubble, Doug Humpheries had a
front panel of a KA (nothing else) stored for giggles.
I would love to have someone point out to me what the backplane really
did. When I was working on KLs, we never went within 5 feet of the FS guys
when they were in there. It looked like the wirewraps were 8 inches deep,
I'm sure it was more like an inch or two.
And I'd love to hold a KL CPU board and figure out how it really connected
to the backplane to make the KL that I loved so much for so many years.
Modern CPUs are just tin cans with feet.
Even my attempt at speculating about what a 72 bit grandson of the PDP-10
dropped into the standard mindless argument.
jmfb...@aol.com
Because Mark has a fixation. I don't let him blame the TOPS-10
group; this was the claim of the -20 group. Bell blamed the
whole PDP-10 product line for the problems.
/BAH
jmfb...@aol.com
My apologies. I will try to avoid reading Crispin's posts from
now on. I can't guarantee this because I keep forgetting.
/BAH
jmfb...@aol.com
Angela Kahealani <ang...@kahealani.com> wrote:
>than to be constructive in the now?
>
>....there have been (fortunately) some positive discussions here,
>about creating some new code for the subject platform "soon now".
>
>I would suggest that preserving what was
>(rather than kvetching about what was),
>and creating something new to extend the code base,
>would be the positive modes of "participation" in "the community".
One of the problems with this is that the stuff that went "wrong"
is also what produced the code that ran. A lot of the things not
done had to do with kind of business DEC was in, the market at
THAT time, and what hardware did and didn't funded (and thus, built
and sold).
>
>It's trivially easy to fall into religious arguments about
>who was, or what designs were,
>"our" saviours and "our" devils,
>what {c,sh}oulda be{,en}, but,
>the bottom line remains:
>"show me the code"...
>....case in point...
>combine the Panda TOPS-20 distro with Spare Time Gizmos Panda Panel,
>and you've got a serious contribution to preserving and extending
>what was good about the PDP-10 architecture.
>For those who believe that TOPS-10 was better than TOPS-20,
>put your code where your mouth is, and update TOPS-10 to
>drive the Panda Panel.
None of this will demonstrate what went wrong and why certain
approaches didn't happen.
> If your religion be hardware,
>then come up with a modern switch panel to go with the display panel.
>As a notable figure in the movement has pontificated:
>"TOPS-20: a great improvement over its successors" -- Mark Crispin
>If you think you can trump the Panda distro, well then...
>"show me the code!"... Go ahead, prove him wrong!
>Not by arguing that "he is wrong", but by outcoding him.
>If you'd rather compete with what he's created,
>than contribute to extend it further, great...
>but do it with code, not with arguments here.
>
>Now that I'm through pontificating,
>I'm going to put some more time into getting my TOPS-20/KLH-10
>running, which reminds me, does anyone have a useful pointer
>(along the lines of, "go RTFM, *this* FM at some URL")
>about how to properly configure Linux to:
>1. stay out of the way of TOPS-20 using its own ethernet interface?
>2. stay out of the way of TOPS-20 using the parallel port
> for the Panda Panel? (this implies the KLH-10 emulator).
>3. where do I RTFM to understand how to join HECNET, and
> whether I will need my own DECNET "area" to do so?
>
>As someone new to the PDP-10 architecture, I've only archived
>19 GigaBytes of code and documentation, and not having had time
>to read through all of that, I'd appreciate the effectiveness
>of a little guru guidance on where to start. Oh, sure, I was
>once an actual USER of TOPS-20, but only now am I beginning to
>learn how to install and administer a Panda TOPS20 KLH-10. So,
>would someone care to tell me which FM to go RTFM?
>
>Thank you, Angela Kahealani
>
Rich Alderson
> I would love to have someone point out to me what the backplane really
> did. When I was working on KLs, we never went within 5 feet of the FS guys
> when they were in there. It looked like the wirewraps were 8 inches deep,
> I'm sure it was more like an inch or two.
> And I'd love to hold a KL CPU board and figure out how it really connected
> to the backplane to make the KL that I loved so much for so many years.
Pat, you're in the Seattle area, aren't you? Drop me a line and I'll get you
set up to visit a couple of KLs with their guts hanging open, and put boards in
your hand as well.
glen herrmannsfeldt
(snip)
> Because Mark has a fixation. I don't let him blame the TOPS-10
> group; this was the claim of the -20 group. Bell blamed the
> whole PDP-10 product line for the problems.
I have no idea of the answer, so I will just ask.
If DEC did everything with the PDP-10 that they did with VAX,
what might have been the result? (That is, VMS on 36 bits.)
Or, to ask another way, how would a 36 bit VAX have done
in the market of the 70's and 80's? (Consider VAX 10/780.)
-- glen
Eric Smith
> This reminds me, there are people on the Hercules project,
> an emulator of IBM mainframes, working on S/380.
> That is, an emulation of a system that never existed,
> but could have, somewhere between S/370 and ESA/390.
Does that have some advantage over emulating the S/370 and ESA/390?
In other words, is there something interesting that can be done
with this mythical S/380 that isn't possible on an emulated ESA/390?
Eric Smith
> And I'd love to hold a KL CPU board
There isn't a "CPU board". Or there's a whole bunch of them, depending
on how you look at it. But you probably already knew that.
> and figure out how it really connected to the backplane to make the KL
I'm sure you must mean something other than "with gold-plated edge
connectors", but I'm not sure what.
> that I loved so much for so many years.
Agree with you there!
Eric
Eric Smith
> If DEC did everything with the PDP-10 that they did with VAX,
> what might have been the result? (That is, VMS on 36 bits.)
No, not VMS on 36 bits. No one wanted that. It would have been an
even better TOPS-20 on 36 bits.
> Or, to ask another way, how would a 36 bit VAX have done
> in the market of the 70's and 80's? (Consider VAX 10/780.)
The -10 didn't need much in the way of the sort of architectural extention
that turned the -11 into a VAX. The -10 architecture was already fine.
What the hardware needed was continued improvement. Yes, cluster boxes
together, but also build boxes with more bits of physical address, that are
faster for the same money, or the same speed for less money. The -10
mostly stopped benefitting from Moore's Law in the late 1970s, while
everything else marched on.
What the software needed is less obvious, but certainly if the
resources that went into building VMS and its layered products had
gone into -10 software instead, some amazing things probably would
have been done.
glen herrmannsfeldt
(snip on S/380)
> Does that have some advantage over emulating the S/370 and ESA/390?
> In other words, is there something interesting that can be done
> with this mythical S/380 that isn't possible on an emulated ESA/390?
More than 24 bit addressing.
The original problem was running gcc, which it seems can't be
done in the available region with 24 bits. (Specifically,
to be able to compile itself.)
The I/O architecture changed completely in ESA/390.
So S/380 has S/370 I/O and 31 bit addressing.
-- glen
glen herrmannsfeldt
> glen herrmannsfeldt wrote:
>>If DEC did everything with the PDP-10 that they did with VAX,
>>what might have been the result? (That is, VMS on 36 bits.)
> No, not VMS on 36 bits. No one wanted that. It would have been an
> even better TOPS-20 on 36 bits.
I asked it that way to remove other possible variables.
>>Or, to ask another way, how would a 36 bit VAX have done
>>in the market of the 70's and 80's? (Consider VAX 10/780.)
> The -10 didn't need much in the way of the sort of architectural extention
> that turned the -11 into a VAX. The -10 architecture was already fine.
As with the -11, the -10 eventually ran out of address bits.
It seems to me that people are really against anything that
isn't eight bit byte addressable, or at least makes it easy to
work with files of eight bit bytes. A 36 bit word system that
would use nine bit bytes would seem mostly compatible with
other systems, as long as the high bit was zero.
I was wondering how important byte addressability was to
the success (while it lasted) of VAX.
-- glen
Mark Crispin
> Because Mark has a fixation. I don't let him blame the TOPS-10
> group; this was the claim of the -20 group. Bell blamed the
> whole PDP-10 product line for the problems.
Sheesh, Barb, talk about fixations! That's two slams in a matter of a few
minutes.
I'm sorry that you cracked up and became unemployable. I'm sorry that you
had such an intense personality conflict with the TOPS-20 developers that
you hated them even worse than you hated VMS.
But instead of whimpering, why don't you do something? If Bottoms-10 was
the greatest thing since sliced bread, why the hell isn't there an active
group of people running and developing on it the way there is for TOPS-20?
We even have a fellow working on a new TOPS-20 FTP server.
Pat Farrell
> I'm sure you must mean something other than "with gold-plated edge
> connectors", but I'm not sure what.
I knew that there were many, I'd like to grab one, know what it was, and
see if there were obvious parts that make sense.
I've taken graduate CS mirco-architecture courses (long after I saw my last
KL) so I have some idea what parts are. I expect that a KA had TTL chips
to do things like be the adder, or decode the effective address.
The KL was a giant blue/orange box. I'd love to grok it internally.
ten or so years ago, I had the pleasure of running into Al Kotok at a
banking conference. It took me a while to remember his name, as the
microcode dude from the greatest computer ever. So we spent the next half
day talking about programming KLs at all levels.
So I'd love to see, is there a physical machine with its own adders and
instruction decoders that executes the microcode? Can the parts be
identified by eyeball?
Etc.
Plus, I just like talking to folks who used KA/KI/KLs
Pat
Pat Farrell
> Pat Farrell <fis...@pfarrell.com> writes:
> Pat, you're in the Seattle area, aren't you?
Wow, that would be great.
I'm in the Washington DC area, but I get out there every once in a while,
and I'll be sure to remember to look you up. I'll buy the beers.
Pat Farrell
> No, not VMS on 36 bits. No one wanted that. It would have been an
> even better TOPS-20 on 36 bits.
Correct, we wanted TOPS-20 on much faster hardware.
That was what I was trying to speculate in the thread:
Subject: What if Twenex was scaled to be current
from Feb 22 of this year. But like most threads here, it
got hijacked by the usual flame wars.
If it had grown, stayed modern, what would it have looked like?
> What the hardware needed was continued improvement. Yes, cluster boxes
> together, but also build boxes with more bits of physical address, that are
> faster for the same money, or the same speed for less money. The -10
> mostly stopped benefitting from Moore's Law in the late 1970s, while
> everything else marched on.
er, the KL was a 1975 or so design, it didn't change much for ten years.
I worked on 1090s in the Marlboro fishbowl in 1977. I can remember the
KL-B model (more cache) but not much else happened.
I don't count the CI, NI stuff, they were Vax parts grafted into a good
computer as a last ditch, cheap life extension hack.
The KL was functionally obsolete by about 1980, if a replacement had come
out then (this is fiction, not reality) that was twice as fast, same price
and same or smaller physical size. less energy waste, etc. Or give the KM
a 1981 date (twice as fast as a KL) and a KN in 1984, twice again as fast.
We at AMS would have kept buying them, and selling them.
Add real DECnet or even TCP/IP for real networking, and the world of
computing would have changed. Crap like Netware would have never existed,
as it would have had to feature compete with Tops-20.
Sometime in the late 1980s, it would have needed extensions to more memory
addressing, but Extended addressing worked on KLs. we used it all the time.
I speculate that 72 bit addressing, words, etc. would come in the early
1990s.
Who knows from there.
Pat
John Sauter
> I speculate that 72 bit addressing, words, etc. would come in the early
> 1990s.
>
> Who knows from there.
>
The instruction set was originally designed for an 18-bit word address.
Extending it to 22 or 23 bits is significantly painful, but the
resulting instruction set is still recognizable to a PDP-10 programmer.
Adding even more address bits would have increased the pain level
considerably. You would have to reorganize byte pointers, probably into
two words. The BLT instruction would need a re-design. A PDP-10 with a
36-bit address would be different enough from the original instruction
set that you would be justified in inventing a new PDP number for it.
Going from 36 to 72 bits would be even worse. Now an address will not
fit in a register, unless you make the registers wider. Unless you also
re-design all the instructions it takes 4 immediate instructions to load
a constant address into a pair of registers. With an address taking two
registers you effectively have half as many registers.
Since you are going to have to re-write all your assembly-language
software for a 36- or 72-bit address, you might as well re-design the
instruction set completely, based on the wide address. With some work
you can make the resulting instruction set architecture appealing to
PDP-10 programmers, for example by using the same mnemonics for
equivalent instructions, but at the bit level it won't be even close to
a PDP-10.
Compare the X86 to the X86-64 for an example. AMD managed to extend the
architecture from 32 to 64 bits and keep much of the flavor of the
32-bit instruction set, but any assembly-language code needs to be
rewritten for 64-bit mode. When the time comes to go to 128 or 256
bits, another re-write will be required.
John Sauter (John_...@systemeyescomputerstore.com)
Pat Farrell
> The instruction set was originally designed for an 18-bit word address.
> Extending it to 22 or 23 bits is significantly painful, but the
> resulting instruction set is still recognizable to a PDP-10 programmer.
From what I remember, the extended addresses would have worked with ~30
bit addresses. But perhaps not depending on indexing and indirect.
We were way past 18 bit addresses by 1981 or so.
I would have been happy with the 22/23 bits of a KL followed by 26 or so
in a KM and 30 in a KN.
> Adding even more address bits would have increased the pain level
> considerably. You would have to reorganize byte pointers, probably into
> two words. The BLT instruction would need a re-design. A PDP-10 with a
> 36-bit address would be different enough from the original instruction
> set that you would be justified in inventing a new PDP number for it.
No problem with me here. Just call it a PDP-30.
> Going from 36 to 72 bits would be even worse. Now an address will not
> fit in a register, unless you make the registers wider.
Of course wide instructions would have wider registers.
With memory getting cheaper, Moore's law and all that, there is no reason
to not have a few gigawords.
> Since you are going to have to re-write all your assembly-language
> software for a 36- or 72-bit address, you might as well re-design the
> instruction set completely, based on the wide address. With some work
> you can make the resulting instruction set architecture appealing to
> PDP-10 programmers, for example by using the same mnemonics for
> equivalent instructions, but at the bit level it won't be even close to
> a PDP-10.
No worry here either. You hack some old PDP-10 emulation mode, doing them
as MUUOs.
Part of the problem with real TOPS-20 machines was the PA1050 was
sufficiently good that there was too little incentive to rewrite
all the tools, CUSPs, etc. into the good new operating system.
I'm making that gross assumption that the TOPS-10 folks would
move to a modern OS once the hardware evolved to support the same kinds of
loads.
As both a systems/OS internals and an application programmer, the TOPS-20
world was a lot more productive of software engineers' time.
> rewritten for 64-bit mode. When the time comes to go to 128 or 256
> bits, another re-write will be required.
Its been at least 20, if not 30 years since folks really expected to write
assembler for big iron. You use C, Bliss, algol, for some new language,
and just change the code emit phase.
My problem with Vaxes and VMS was not that it couldn't handle the load of
our KLs. It was that the OS was lame. It got better, but there was no
reason to step back in OS history. By the early 80s, the power to build on
Multic and Tenex was there. Instead, we dropped back into overgrown
mini-computers which, IMHO, were rejected in favor of far weaker PCs.
VMS' paging was just one example of ignoring 10 years of computer science
research.
Eric Smith
> As with the -11, the -10 eventually ran out of address bits.
It didn't. DEC stopped building and selling them before the
architectural limits were hit. The architecture offered 30-bit
per-process addressing (1 GW), and 27-bit physical addressing (128MW).
The KL10 only supported 23-bit per-process addressing (8 MW), and only
22-bit physical addressesing (4 MW), but those were implementation
limits, not architectural limits.
Of course, had DEC continued promoting the PDP-10 architecture, by
the late 1990s they would have had to extend the architecture again.
Increasing the physical address space could be done by altering the
format of page tables, without any repercussions on user code.
Increasing the per-process addressing beyond 30 bits while retaining
compatibility would have been more challenging.
> I was wondering how important byte addressability was to
> the success (while it lasted) of VAX.
It was important for customers migrating from the byte-oriented PDP-11.
DEC tried omitting byte instructions on the Alpha, and later had to add
them back in.
Eric Smith
> The -10 mostly stopped benefitting from Moore's Law in the late 1970s, while
> everything else marched on.
Pat Farrell wrote:
> er, the KL was a 1975 or so design, it didn't change much for ten years.
> I worked on 1090s in the Marlboro fishbowl in 1977. I can remember the
> KL-B model (more cache) but not much else happened.
The 1095/2065 upgrade expanded the cache and pager. That's why I was
giving it the benefit of the doubt by saying "late 1970s".
> The KL was functionally obsolete by about 1980,
You won't get any argument from me on that.
Eric
Jean-Marc Bourguet
> Of course, had DEC continued promoting the PDP-10 architecture, by
> the late 1990s they would have had to extend the architecture again.
The same kind of architectural considerations which made the Alpha replaces
the VAX would have hit the TDP-10 at the end of the 80's or in the early
90's. One could have had a 36 bits or 72 bits RISC, but it would have more
in common with the Alpha than with the TDP-10.
Yours,
--
Jean-Marc
John Sauter
>
> Its been at least 20, if not 30 years since folks really expected to write
> assembler for big iron. You use C, Bliss, algol, for some new language,
> and just change the code emit phase.
>
> My problem with Vaxes and VMS was not that it couldn't handle the load of
> our KLs. It was that the OS was lame. It got better, but there was no
> reason to step back in OS history. By the early 80s, the power to build on
> Multic and Tenex was there. Instead, we dropped back into overgrown
> mini-computers which, IMHO, were rejected in favor of far weaker PCs.
>
> VMS' paging was just one example of ignoring 10 years of computer science
> research.
Thirty years ago, writing in assembly language for the KL10 was
considered normal. The VAX was unusual in having a good enough
medium-level language, and enough address space, that you didn't have to
use assembly language for system programming. I wrote a PDP-11 task
builder for the PDP-10, and my use of Bliss was considered strange.
With the advantage of hindsight we can see that the operating systems
which have survived are Microsoft Windows and various implementations of
Unix. Microsoft Windows was written by David Cutler, and based on his
previous operating systems: VAX/VMS, RSX-11M and one whose name I don't
know that he wrote while at DuPont. See
<http://www3.sympatico.ca/n.rieck/docs/Windows-NT_is_VMS_re-implemented.html#forward>
for details. Unix was developed as a reaction to the size of Multix.
For economic reasons, most of today's computers are descended from the
small computers of 20 years ago, not the large ones. The exceptions are
IBM's "big iron", though GNU/Linux has also been ported to them,
probably because more people are familiar with Unix than with IBM's
operating systems. Had the PDP-10 survived I think it would have
followed the same path as the IBM System/360: larger addresses, new
instructions, compatibility mode to run old programs, a GNU/Linux port
starting to displace TOPS-20, and relegated to an industry niche.
It could happen again--the computers of 20 years from now might not be
descended from today's PCs but from one of today's embedded CPUs.
Some of the VAX/VMS developers were quite familiar with TOPS-20.
We brought the ideas of TOPS-20 into the VAX, and with time that
operating system improved.
John Sauter (John_...@systemeyescomputerstore.com)
glen herrmannsfeldt
(snip)
> Going from 36 to 72 bits would be even worse. Now an address will not
> fit in a register, unless you make the registers wider. Unless you also
> re-design all the instructions it takes 4 immediate instructions to load
> a constant address into a pair of registers. With an address taking two
> registers you effectively have half as many registers.
(snip)
IBM successfully took S/360 from 24 to 31, and then to 64 bits.
64 bits doubles the size of the registers, with old instructions
using the low half of the registers. Base displacement addressing
helps in not requiring larger displacement fields, though they also
have some support for that.
> Compare the X86 to the X86-64 for an example. AMD managed to extend the
> architecture from 32 to 64 bits and keep much of the flavor of the
> 32-bit instruction set, but any assembly-language code needs to be
> rewritten for 64-bit mode. When the time comes to go to 128 or 256
> bits, another re-write will be required.
64 bit addressing should last a while. Hopefully something will
replace x86 by then.
-- glen
jmfb...@aol.com
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>jmfb...@aol.com wrote:
>
>(snip)
>
>> Because Mark has a fixation. I don't let him blame the TOPS-10
>> group; this was the claim of the -20 group. Bell blamed the
>> whole PDP-10 product line for the problems.
>
>I have no idea of the answer, so I will just ask.
>
>If DEC did everything with the PDP-10 that they did with VAX,
>what might have been the result? (That is, VMS on 36 bits.)
They did do everything but write the monitor in BLISS.
The VAX didn't deliver user thruput until the -10 and -20
people started working in the VAX product line.
>
>Or, to ask another way, how would a 36 bit VAX have done
>in the market of the 70's and 80's? (Consider VAX 10/780.)
It would have done terrible just like it did. The VAX wasn't
a PDP-n. The hardware configuration was for a small set of
users. It was not a mainframe.
/BAH
jmfb...@aol.com
The PDP-10 did not exclude 9-bit bytes. You keep making this
mistaken assumption. The -10 could manipulate any n-bit bytes.
That's what made the architecture a general timesharing system.
The PDP-10 software was not tied to any nth-bit bytes.
>
>I was wondering how important byte addressability was to
>the success (while it lasted) of VAX.
/BAH
Pat Farrell
> Thirty years ago, writing in assembly language for the KL10 was
> considered normal.
Lets see, 30 years ago was 1977. Yes, in 77 folks wrote in assembly
language.
But large shops did a ton of work in higher level languages by 1980. PL/1
on Multics was a massive example. Bliss on 11/van/kl was another.
Bliss was ugly and a lot of traditionalists didn't like it.
But as much as I loved Macro, it wasn't the answer long term.
> medium-level language, and enough address space, that you didn't have to
> use assembly language for system programming. I wrote a PDP-11 task
> builder for the PDP-10, and my use of Bliss was considered strange.
The vax instruction set was designed to be C. Or C was designed to be
the language for 11s, which begat vax.
> With the advantage of hindsight we can see that the operating systems
> which have survived are Microsoft Windows and various implementations of
> Unix. Microsoft Windows was written by David Cutler, and based on his
> previous operating systems: VAX/VMS, RSX-11M and one whose name I don't
> know that he wrote while at DuPont.
Yes, we are cursed today with the legacy of Cutler not understanding large
systems.
> Some of the VAX/VMS developers were quite familiar with TOPS-20. We
> brought the ideas of TOPS-20 into the VAX, and with time that operating
> system improved.
Interesting. I stopped caring by 85 or 86. I sure didn't see much evidence
of this. The Marlborough and Maynard folks appeared to be on different
planets.
Antonio Carlini
news:m37ig4v...@donnybrook.brouhaha.com:
> glen herrmannsfeldt
>> I was wondering how important byte addressability was to
>> the success (while it lasted) of VAX.
>
> It was important for customers migrating from the byte-oriented PDP-11.
>
> DEC tried omitting byte instructions on the Alpha, and later had to add
> them back in.
That was, iirc, because Windows NT depended heavily on
byte instructions. I've no idea whether anything else
really cared.
Antonio
Jim Haynes
Pat Farrell <fis...@pfarrell.com> wrote:
>
>Lets see, 30 years ago was 1977. Yes, in 77 folks wrote in assembly
>language.
>
Algol.
Rich Alderson
Rich Alderson
> glen herrmannsfeldt
>> As with the -11, the -10 eventually ran out of address bits.
> It didn't. DEC stopped building and selling them before the architectural
> limits were hit. The architecture offered 30-bit per-process addressing (1
> GW), and 27-bit physical addressing (128MW).
It's been a very long time since I saw the extended-addressing specs, but was
there really a 27-bit physical limit in the DEC original??? Why???
On the XKL-1 processor in the Toad-1, you get 30-bit physical addressing.
TOPS-20 won't let you have section 7777, but that's an OS implementation
detail, not hardware.
Rich Alderson
> On Fri, 14 Mar 2008 22:59:11 -0400, John Sauter wrote:
>> The instruction set was originally designed for an 18-bit word address.
>> Extending it to 22 or 23 bits is significantly painful, but the
>> resulting instruction set is still recognizable to a PDP-10 programmer.
> From what I remember, the extended addresses would have worked with ~30
> bit addresses.
Indeed they do. The Toad-1 is an existence proof.
> But perhaps not depending on indexing and indirect.
Why? MOVE T1,@0(P3) works just fine with a 30-bit address in P3.
Mark Crispin
> Correct, we wanted TOPS-20 on much faster hardware.
Absolutely correct. The failure of Jupiter was an incredible blow,
especially given what a modest (and years-delayed) upgrade it was.
> If it had grown, stayed modern, what would it have looked like?
On the bad side, large parts of it would probably have been rewritten in
BLISS; and we'd have long flamewars on the merits of BLISS vs. C rather
than seeing BLISS die.
On the good side:
Almost certainly the EXEC would have been replaced or at least the
capability to have an alternative shell would be a general user feature
rather than a hacker's toy.
Piping would have become much better supported.
Our friends in the UNIX world would have been under considerable pressure
to implement locks on the level of ENQ/DEQ rather than the garbage
(flock() and POSIX fcntl() locking) that we have to put up with today.
Speaking of cross-pollination, we'd have some equivalent to the UNIX /proc
filesystem rather than new jsi to manipulate things; and our friends in
UNIX would have a filesystem accessible network interface rather than
(ugh, cough, bletch) sockets.
Depends upon how you look at it side:
The memory model would have been substantially simplified so that it would
be reasonable to implement in a chip. Whenever hardware designers look at
the PDP-10, the basic instructions are quite easy enough to do but the
paging architecture causes them to scream and pull hair.
We'd still have people debating the merits of MACRO vs. MIDAS vs. FAIL.
;-)
Mark Crispin
> It's been a very long time since I saw the extended-addressing specs, but was
> there really a 27-bit physical limit in the DEC original??? Why???
You have to redo the entire pager architecture (and redefine some jsi)
after 27 bits, because lots of things depend upon a page number being no
more than 18 bits.
> On the XKL-1 processor in the Toad-1, you get 30-bit physical addressing.
> TOPS-20 won't let you have section 7777, but that's an OS implementation
> detail, not hardware.
Ralph had to do a great deal of work for those last three bits...
Mark Crispin
>> It seems to me that people are really against anything that
>> isn't eight bit byte addressable, or at least makes it easy to
>> work with files of eight bit bytes. A 36 bit word system that
>> would use nine bit bytes would seem mostly compatible with
>> other systems, as long as the high bit was zero.
> The PDP-10 did not exclude 9-bit bytes. You keep making this
> mistaken assumption. The -10 could manipulate any n-bit bytes.
> That's what made the architecture a general timesharing system.
> The PDP-10 software was not tied to any nth-bit bytes.
Nobody is making any such "mistake assumption". Some of us actually spent
considerable time working with interoperability between the byte world and
the 36-bit world. Notwithstanding the byte instructions, this was NOT as
easy as it might seem to someone who has never worked in that area.
For more information, look into the FTP specification and review the
differences between "text", "binary", "paged", and "L 8" file. This
incredible complexity was brought about by the 36-bit world. It was a
cause of considerable backlash against the 36-bit world since within the
byte world none of this was necessary.
No arguments about how wonderful the PDP-10 byte instructions are could
convince users who encountered the excessive complexity in file transfer
and the inevitable file corruption in transfer caused by using the wrong
combination of modes.
The users just wanted something that worked; and sadly the PDP-10's
sustantially different data architecture got in the way of making things
"just work" when multi-system interoperability was needed.
Mike Ross
wrote:
>This reminds me, there are people on the Hercules project,
>an emulator of IBM mainframes, working on S/380.
>That is, an emulation of a system that never existed,
>but could have, somewhere between S/370 and ESA/390.
<trivia> The S/380 was *possibly* the designation for the never-completed FS
project. Some of which got reused in the midrange System/38 - which might
explain why the midrange has S/32, then S/34, then S/38, then, significantly
later, S/36...
BTW, just in case there's anyone lurking here who's into IBM, I'm becoming
desperate for a 3340 disk drive and 3277 terminal...
Mike
--
http://www.corestore.org
'As I walk along these shores
I am the history within'
Mike Ross
You're a lot closer to NYC then, where I can also offer KL hardware-fondling
experiences...
Mike Ross
>On Fri, 14 Mar 2008 17:03:03 -0700, Eric Smith wrote:
>> No, not VMS on 36 bits. No one wanted that. It would have been an
>> even better TOPS-20 on 36 bits.
>
>Correct, we wanted TOPS-20 on much faster hardware.
>
>That was what I was trying to speculate in the thread:
>Subject: What if Twenex was scaled to be current
>from Feb 22 of this year. But like most threads here, it
>got hijacked by the usual flame wars.
>
>If it had grown, stayed modern, what would it have looked like?
Intriguing. Just for fun, have a look on the blue side of the fence... VM and
MVS are both more ancient in origin than TOPS-anything, and *have* grown and
(arguably) stayed modern. (FSSVO 'modern', some would say!).
Look at what they've thrown away, what they've kept, and where they've grown new
capabilities.
glen herrmannsfeldt
>> The PDP-10 did not exclude 9-bit bytes. You keep making this
>> mistaken assumption. The -10 could manipulate any n-bit bytes.
>> That's what made the architecture a general timesharing system.
>> The PDP-10 software was not tied to any nth-bit bytes.
> Nobody is making any such "mistake assumption". Some of us actually
> spent considerable time working with interoperability between the byte
> world and the 36-bit world. Notwithstanding the byte instructions, this
> was NOT as easy as it might seem to someone who has never worked in that
> area.
Right. It isn't the hardware but the standard text file format
using five 7 bit characters per word. Eight bit data (binary or
EBCDIC text) can't be copied to that form and back again.
There needs to be two types of conversions between 36 bit words
and eight bit data, one that preserves the 8 bit data and one that
preserves 36 bit words. I do remember by favorite test of 9 track
tapes was to copy the COBOL compiler to the tape a few times, and
then copy it back again. I also used to read EBCDIC 9 track tapes
on TOPS-10.
Text files using four characters per word would have simplified
much of working with eight bit data. Also, C char is required to
be at least eight bits. I believe nine is a good choice for C
on the PDP-10.
-- glen
glen herrmannsfeldt
(snip)
> The memory model would have been substantially simplified so that it
> would be reasonable to implement in a chip. Whenever hardware designers
> look at the PDP-10, the basic instructions are quite easy enough to do
> but the paging architecture causes them to scream and pull hair.
I never looked into it much. In the days I was interested in such
I was using a KA-10 with no paging. As an undergrad I did write a
paper explaining the similarities between VAX paging and S/370
paging (both use a two level indexing system).
-- glen
glen herrmannsfeldt
(snip)
> My problem with Vaxes and VMS was not that it couldn't handle the load of
> our KLs. It was that the OS was lame. It got better, but there was no
> reason to step back in OS history. By the early 80s, the power to build on
> Multic and Tenex was there. Instead, we dropped back into overgrown
> mini-computers which, IMHO, were rejected in favor of far weaker PCs.
If VAX and VMS were more affordable they might have lasted longer.
> VMS' paging was just one example of ignoring 10 years of computer science
> research.
Well, also that they were looking back instead of ahead.
The page size was way too small for the near or not so near
future when it was designed. (Though you can always page
in multiples of the hardware page size.)
-- glen
John Sauter
You are thinking of the Burroughs B5500, which had an instruction set
tailored to Algol-60. This allowed the Algol compiler to be small and
fast. It also had a (very different) instruction set for COBOL.
However, this design decision effectively limited the machine to these
two languages--Espol was a dialect of Algol, and the Fortran compiler
output Algol, which was then compiled by the Algol compiler.
For better or worse, the PDP-10 instruction set was designed to appeal
to assembly-language programmers, not to Algol, COBOL or Fortran compilers.
John Sauter (John_...@systemeyescomputerstore.com)
John Sauter
> 64 bit addressing should last a while. Hopefully something will
> replace x86 by then.
>
Today we are near the end of the transition from 32- to 64-bit
computers. The transition started around 1992, with the Alpha.
The industry consumes about one bit every 18 months, so we should begin
to see computers with more than 64 bits around 2040.
Applying the same hand-waving analysis to the PDP-10, the KL10 model B
with extended addressing was introduced in 1978, so call that the end of
18-bit addresses. The 23-bit address would then last until 1985, when
DEC should have introduced the PDP-36 with 36-bit addresses. That would
have lasted until 2005, by which time the PDP-72 needed to be ready.
A computer with 72 bits of address space would have remained viable
until 2059.
John Sauter (John_...@systemeyescomputerstore.com)
Pat Farrell
> On the bad side, large parts of it would probably have been rewritten in
> BLISS; and we'd have long flamewars on the merits of BLISS vs. C rather
> than seeing BLISS die.
Since this is a dream, I can dream that C died as well and we moved to D
or some higher level language. C was and is far too close to PDP-11
assembly language for my tastes. Specify what you want done, let
the compiler figure out how to do it.
Of course folks used to doing MACRO/FAIL would never make the transition.
> Almost certainly the EXEC would have been replaced or at least the
> capability to have an alternative shell would be a general user feature
> rather than a hacker's toy.
Some of that was starting to happen, CMU's PCL comes to mind.
Actually at AMS, we had alternative shells for most users from about 78
on. Sadly, our goal was less functionality (padded cell) rather than more.
> Piping would have become much better supported.
Which would have been wonderful.
> Speaking of cross-pollination, we'd have some equivalent to the UNIX /proc
> filesystem rather than new jsi to manipulate things; and our friends in
> UNIX would have a filesystem accessible network interface rather than
> (ugh, cough, bletch) sockets.
Yeah, competition improves the world.
> We'd still have people debating the merits of MACRO vs. MIDAS vs. FAIL.
> ;-)
I see the smiley. With C/Bliss/D/Java I think 99% of the folks would move
away from bit banging.
I've been a professional software developer for nearly 40 years, with lots
of MACRO on both 10s and 20s. I think its been seven or eight years since
I did any really low level stuff. We work at a higher level of abstraction
these days.
Pat Farrell
> You're a lot closer to NYC then, where I can also offer KL hardware-fondling
> experiences...
Yes, my kid lives in Brooklyn, we were up there just a couple of weeks ago.
Same offer from me that I made to Rich, I'll buy the beer.
glen herrmannsfeldt
(snip)
> Today we are near the end of the transition from 32- to 64-bit
> computers. The transition started around 1992, with the Alpha.
> The industry consumes about one bit every 18 months, so we should begin
> to see computers with more than 64 bits around 2040.
I don't think we are quite that far along. While most machines
sold now have 64 bit capable processors, most are still running
32 bit code, and have less than 4GB real memory. Maybe Alpha
was too early. If Intel had but a 36 bit MMU on x86 it likely
would have lasted even longer at 32 bit.
> Applying the same hand-waving analysis to the PDP-10, the KL10 model B
> with extended addressing was introduced in 1978, so call that the end of
> 18-bit addresses. The 23-bit address would then last until 1985, when
> DEC should have introduced the PDP-36 with 36-bit addresses. That would
> have lasted until 2005, by which time the PDP-72 needed to be ready.
> A computer with 72 bits of address space would have remained viable
> until 2059.
With 36 bit words, you get about an extra two bits in terms of
addressable address space (ln(36)/ln(8)). For the majority of
users, 64G of 36 bit words should be enough for a few years more.
-- glen
glen herrmannsfeldt
(snip)
> You are thinking of the Burroughs B5500, which had an instruction set
> tailored to Algol-60.
The first machine I ever wrote programs on!
> For better or worse, the PDP-10 instruction set was designed to appeal
> to assembly-language programmers, not to Algol, COBOL or Fortran compilers.
The PDP-10 is a little RISC-y, though. One instruction size and a
small number of address modes. It seems to me that VAX was also
designed for assembly programmers.
-- glen
John Sauter
> The PDP-10 is a little RISC-y, though. One instruction size and a
> small number of address modes. It seems to me that VAX was also
> designed for assembly programmers.
>
I would say that the PDP-11 was designed for assembly-language
programmers, and the VAX borrowed heavily from it.
John Sauter (John_...@systemeyescomputerstore.com)
Pat Farrell
> The PDP-10 is a little RISC-y, though. One instruction size and a
> small number of address modes. It seems to me that VAX was also
> designed for assembly programmers.
More realistically, the Vax was designed before the whole RISC/CISC
argument got hot. It is generally considered one of the most Complex
instruction sets (altho I think the Multics guys can argue)
with all the auto increment, self indirection, etc. Plus of course, the
early 780s vintage models had things like single instructions that did all
the control for a Fortran DO LOOP, and even a polynomial evaluation
"instruction"
To be far to the VMS world, within a few years the function libraries were
amazing. It allowed engineers to easily make applications do amazing stuff.
And the libraries were good, they took real effort to do the numeric
analysis properly.
At the time, being able to write small code was a big deal, as memory was
still pretty expensive (and disks were expensive) so small was good.
I spent a little time comparing some Burroughs midi-sized machines against
Vaxen for a Federal RFP. The Burroughs were actually impressive -- and I
was at the time a 10+ year DEC guy
Pat Farrell
> I don't think we are quite that far along. While most machines
> sold now have 64 bit capable processors, most are still running
> 32 bit code, and have less than 4GB real memory.
Anyone got solid numbers for actual use of 64 bit OS?
Apple's OS-X is 64 bit, but nearly all Windows users are in 32 bits, and
I would expect the majority of Linux desktops.
Big iron LAMP machines are of course 64 bit, but they tend to have a
lot of memory, far more than 4GB.
> Maybe Alpha was too early.
I think it probably was. There was not a lot of compelling reasons
to move to 64 bit stuff then.
> With 36 bit words, you get about an extra two bits in terms of
> addressable address space (ln(36)/ln(8)). For the majority of users,
> 64G of 36 bit words should be enough for a few years more.
Do you mean from the user view? or the system view?
I think that from the user's view, I agree. But multi-user systems
have always demanded lots of real memory.
I'm a bit fuzzy on the details, but I am pretty sure that vintage 82, our
KLs had about as much real memory as our IBM mainframes. The IBM gear had
tons faster IO with their attached channels, but they didn't have all that
much memory. The CICS world was used to very small 'per application'
memory constraints.
VM/CMS was altogether a separate story, of course.
glen herrmannsfeldt
> glen herrmannsfeldt wrote (excerpted):
>> The PDP-10 is a little RISC-y, though. One instruction size and a
>> small number of address modes. It seems to me that VAX was also
>> designed for assembly programmers.
> I would say that the PDP-11 was designed for assembly-language
> programmers, and the VAX borrowed heavily from it.
There is that, but a lot got added for VAX. Especially all
the decimal arithmetic that I don't remember for PDP-11.
Also, the huge number of addressing modes. Compiled code
tends to use a small number of addressing modes, one
reason for RISC.
-- glen
glen herrmannsfeldt
(snip, I wrote)
>>With 36 bit words, you get about an extra two bits in terms of
>>addressable address space (ln(36)/ln(8)). For the majority of users,
>>64G of 36 bit words should be enough for a few years more.
> Do you mean from the user view? or the system view?
> I think that from the user's view, I agree. But multi-user systems
> have always demanded lots of real memory.
It is really user address space that is the question. There are
tricks that can be played for physical addressing, such as extra
bits in page table entries (S/370 did that).
For user space there are things like segment selectors in x86.
For the 80386, you have a 45 bit virtual address space
(32 bit offset, 16 bit segment selector, -3 for ring and local/global).
All would be fine if they didn't put a 32 bit MMU in between that and
the 36 bit physical address bus (on later processors).
Large model x86 code isn't that hard to write.
I don't understand the later PDP-10 addressing modes
enough to say anything about them. How hard is it to get
to 36 bit addressing seen by users?
-- glen
Roger Ivie
> There is that, but a lot got added for VAX. Especially all
> the decimal arithmetic that I don't remember for PDP-11.
There was a commercial instruction set option for some models
that included string and decimal instructions.
--
roger ivie
ri...@ridgenet.net
Pat Farrell
> I don't understand the later PDP-10 addressing modes
> enough to say anything about them. How hard is it to get
> to 36 bit addressing seen by users?
It was easy in MACRO and Bliss.
I don't think any of the DEC supported High Level languages (which were
really just Fortran and Cobol, altho there was an Algol compiler, and the
academics used Lisp, etc.) ever had compilers smart enough to use extended
addressing.
I was several years into using Tops-20 before I tried them, probably 1979
or maybe 80, so I don't know if Tops-10 had equivalent support.
The trick was that you had to execute in a non-zero 'section', as the zero
section used old style addressing for backwards compatibility.
With Macro or Bliss it was trivial, just a few instructions to setup a
mapping between section zero (the default) and any non-zero section, and
then magically, all the long address stuff worked. It was pretty amazing.
early microcode required two word byte pointers, but later verisons
supported OWGBP (one word global byte pointers) for the usual byte sizes
that everyone used (typically 7 bit for ascii, etc.)
We had hundreds of Cobol programmers who used our tool libraries, they
were using extended addressing, but they didn't know it. All they knew was
that their programs ran and ran fast.
As a giggle, one night I setup a chain of indirect page addresses, putting
an indirect pointing to the next page in all 22 bits of addressing. Of
course, the instruction could not execute, it would page fault chasing
indirect bits. But it ran up zero CPU time as well.
Pat
Morten Reistad
Pat Farrell <fis...@pfarrell.com> wrote:
>On Fri, 14 Mar 2008 17:03:03 -0700, Eric Smith wrote:
>> No, not VMS on 36 bits. No one wanted that. It would have been an
>> even better TOPS-20 on 36 bits.
>
>Correct, we wanted TOPS-20 on much faster hardware.
>
>That was what I was trying to speculate in the thread:
>Subject: What if Twenex was scaled to be current
>from Feb 22 of this year. But like most threads here, it
>got hijacked by the usual flame wars.
>
>If it had grown, stayed modern, what would it have looked like?
The EA calculation stays in the way of pipelining, because it can
stall everything when the indirect bits are used. With today's speculative
execution trees it would probably not be a huge penalty to implement, but
with late 1980's technology it would.
>> What the hardware needed was continued improvement. Yes, cluster boxes
>> together, but also build boxes with more bits of physical address, that are
>> faster for the same money, or the same speed for less money. The -10
>> mostly stopped benefitting from Moore's Law in the late 1970s, while
>> everything else marched on.
>
>er, the KL was a 1975 or so design, it didn't change much for ten years.
>I worked on 1090s in the Marlboro fishbowl in 1977. I can remember the
>KL-B model (more cache) but not much else happened.
>
>I don't count the CI, NI stuff, they were Vax parts grafted into a good
>computer as a last ditch, cheap life extension hack.
>The KL was functionally obsolete by about 1980, if a replacement had come
>out then (this is fiction, not reality) that was twice as fast, same price
>and same or smaller physical size. less energy waste, etc. Or give the KM
>a 1981 date (twice as fast as a KL) and a KN in 1984, twice again as fast.
>
>We at AMS would have kept buying them, and selling them.
>
>Add real DECnet or even TCP/IP for real networking, and the world of
>computing would have changed. Crap like Netware would have never existed,
>as it would have had to feature compete with Tops-20.
The KM, at least, would have had to address graphics support. Something
like X, or similar would have had to be supported. This requires a great
deal of memory.
>Sometime in the late 1980s, it would have needed extensions to more memory
>addressing, but Extended addressing worked on KLs. we used it all the time.
>
>I speculate that 72 bit addressing, words, etc. would come in the early
>1990s.
Perhaps there wouls have been dual MIPS/PDP10 chips with 64/72 bit addressing,
and 48 bits or so visible externally?
>Who knows from there.
The big question is the killer micros. If the KM-10 could have supplemented
them as a hub, like Novell did with abysmal functionality, then it would
have had a huge market inside the fortune-500's.
-- mrr
Morten Reistad
Pat Farrell <fis...@pfarrell.com> wrote:
>On Sun, 16 Mar 2008 09:49:35 +0900, Mark Crispin wrote:
>> On the bad side, large parts of it would probably have been rewritten in
>> BLISS; and we'd have long flamewars on the merits of BLISS vs. C rather
>> than seeing BLISS die.
>
>Since this is a dream, I can dream that C died as well and we moved to D
>or some higher level language. C was and is far too close to PDP-11
>assembly language for my tastes. Specify what you want done, let
>the compiler figure out how to do it.
>
>Of course folks used to doing MACRO/FAIL would never make the transition.
let us turn the question; what nice tops20 features could we still
rescue for the great masses by porting them to Linux/Unix ?
Linux/Unix has drawn a great deal on Tops20. Linux has leaned quite
a lot on Tops20 internally too.
I would volunteer the following for Linux/Unix :
Comnd%. Library? kernel module, even?
An exec that knows the state of commands. It would probably need somthing
like pcl to describe input to common commands.
enq/deq.
The tops20 fork% model, where the thread and the moby are completely
separate entities.
From other systems I would like the message passing semantics from
QNX (it is probably a few hundred lines of code, but it needs kernel
support) and the semaphores from multics/primos. (sem$nf/sem$wt/sem$dr)
Could the file system semantics from Tops20 be retrofitted too?
And, a decent macro processor in front of the development language.
And, ddt.
Those two were the bits I missed the most when I ended in a job using
Primos after exposure to tops20.
>> Almost certainly the EXEC would have been replaced or at least the
>> capability to have an alternative shell would be a general user feature
>> rather than a hacker's toy.
>
>Some of that was starting to happen, CMU's PCL comes to mind.
>
>Actually at AMS, we had alternative shells for most users from about 78
>on. Sadly, our goal was less functionality (padded cell) rather than more.
>
>
>> Piping would have become much better supported.
>
>Which would have been wonderful.
>
>
>
>> Speaking of cross-pollination, we'd have some equivalent to the UNIX /proc
>> filesystem rather than new jsi to manipulate things; and our friends in
>> UNIX would have a filesystem accessible network interface rather than
>> (ugh, cough, bletch) sockets.
>
>Yeah, competition improves the world.
>
>
>> We'd still have people debating the merits of MACRO vs. MIDAS vs. FAIL.
>> ;-)
>
>I see the smiley. With C/Bliss/D/Java I think 99% of the folks would move
>away from bit banging.
>
>I've been a professional software developer for nearly 40 years, with lots
>of MACRO on both 10s and 20s. I think its been seven or eight years since
>I did any really low level stuff. We work at a higher level of abstraction
>these days.
I seem to get to do forays into bits, still. Sometimes the library
stack gets to be far to tall, and you need to handle bits.
-- mrr
Morten Reistad
John Sauter <John_...@systemeyescomputerstore.com> wrote:
>Pat Farrell wrote (excerpted):
>
>> I speculate that 72 bit addressing, words, etc. would come in the early
>> 1990s.
>>
>>
>
>The instruction set was originally designed for an 18-bit word address.
>Extending it to 22 or 23 bits is significantly painful, but the
>resulting instruction set is still recognizable to a PDP-10 programmer.
>
>considerably. You would have to reorganize byte pointers, probably into
>two words. The BLT instruction would need a re-design. A PDP-10 with a
>36-bit address would be different enough from the original instruction
>set that you would be justified in inventing a new PDP number for it.
Yes, but it could be done quite nicely, by extending the fields.
The 36-bits has 9 bits of instruction, 4 + 1 + 4 as ac, indirect,
index plus 18 bits address. What if we just extended it ?
Both 10 + 10 + 2 + 10, and 32 bit address (for 64 bits, and 1024 registers) and
10 + 12 + 2 + 12 and 36 bit address (for 72 bits, and 4096 registers)
for 32G or 576G bytes of address space, respectively. The words would
keep 8 og 9 8-bit bytes without wastage.
The byte pointer could be expanded similarly.
Another bit for instructions; it is tight enough to find new room for
new instructions, and another bit for indirection; for two indirection
modes that don't stall pipeline as the EA does.
With such an amount of registers, they could be used for all kinds of
base offsets.
I don't see any major obstacles in assembling existing macro/sail/fail
sources to such a format.
>Going from 36 to 72 bits would be even worse. Now an address will not
>fit in a register, unless you make the registers wider. Unless you also
>re-design all the instructions it takes 4 immediate instructions to load
>a constant address into a pair of registers. With an address taking two
>registers you effectively have half as many registers.
>
>Since you are going to have to re-write all your assembly-language
>software for a 36- or 72-bit address, you might as well re-design the
>instruction set completely, based on the wide address. With some work
>you can make the resulting instruction set architecture appealing to
>PDP-10 programmers, for example by using the same mnemonics for
>equivalent instructions, but at the bit level it won't be even close to
>a PDP-10.
No, you can keep the instructions and the semantics. Existing sources
written according to normal best practice should be able to build
without problems.
>Compare the X86 to the X86-64 for an example. AMD managed to extend the
>architecture from 32 to 64 bits and keep much of the flavor of the
>32-bit instruction set, but any assembly-language code needs to be
>rewritten for 64-bit mode. When the time comes to go to 128 or 256
>bits, another re-write will be required.
No, that is the wrong way. I can accept a re-build from sources, but
not a rewrite.
-- mrr
jmfb...@aol.com
Morten Reistad <fi...@last.name> wrote:
>let us turn the question; what nice tops20 features could we still
>rescue for the great masses by porting them to Linux/Unix ?
Only the -20? I would like SET WATCH FILES VERSION
and address break.
<snip list>
>And, ddt.
Definitely. That would show kiddies how the machine works.
<snip>
/BAH
jmfb...@aol.com
John Sauter <John_...@systemeyescomputerstore.com> wrote:
>glen herrmannsfeldt wrote (excerpted):
>
>> The PDP-10 is a little RISC-y, though. One instruction size and a
>> small number of address modes. It seems to me that VAX was also
>> designed for assembly programmers.
>>
>I would say that the PDP-11 was designed for assembly-language
>programmers, and the VAX borrowed heavily from it.
Bell's edict that all code will be written in BLISS would have
eliminated assembly language considerations in designs.
/BAH