the PDP10 retained traditional, non-reentrant "return jump" instructions, where the first word of your subroutine was
overwritten with a jump to the point following the call. To return from sub you jump (perhaps indirectly) through address 0 in your
subroutine.
Actually, the PDP-10 offered a variety of subroutine call instructions, of which that was one. The more commonly used PUSHJ and POPJ instructions implemented a stack-based calling convention, and supported full reentrancy.
though reentrancy and auto variables generally
were a novel feature.
Only in FORTRAN.
Re:The KL10 more powerful than the VAX 11/780????
on
PDP-10 Revival
·
· Score: 2
The PDP10 was limited to
256K words of memory (36bit).
Not so. The KL10 supported 4 Mwords of physical
memory, equivalent to 18 Mbytes in modern term. Quite impressive for 1975. And the per-process virtual address space was 8 Mwords.
When the VAX-11/780 was shipped in 1978, although it had a larger
address space (512 MB physical, 2 GB virtual), the maximum amount of physical RAM it could be configured with was 2 MB. This limit was later raised, but it shows that of the PDP-10s and VAXen available in the same time frame, the PDP-10 was clearly superior in most regards.
and similar processing speed approximately 1 MIPS
The KL10 benchmarked at more than twice the performance of an VAX-11/780 on most workloads.
Pretty neat how the 1975 machine was a significant improvement on its 1978 "successor"!
In fact, the VAX-11/780 performance was so disappointing that they had to cancel the PDP-11/74 (four-processor SMP version of the 11/70), because it was expected to be much more
cost-effective than the VAX.
Re:The KL10 more powerful than the VAX 11/780????
on
PDP-10 Revival
·
· Score: 2
The VAX11 hardware had virtual memory support.
The PDP-10 hardware had virtual memory support, in the KI10 (1972) and all following models. And in some regards, its virtual memory was better designed. But the VAX developers deliberately did NOT want to do anything the same way the PDP-10 did it, regardless of whether the PDP-10 way was good or bad.
It was developed to support VMS, while PDP10 did not.
PDP-10 users consider it to be a huge advantage that the PDP-10 does not run VMS.
You could equally well say that the PDP-10 was developed to support TOPS-10 and TOPS-20, and the VAX was not.
Re:Are there that many PDP-10s still in use?
on
PDP-10 Revival
·
· Score: 1
Would you mind letting me know what company? I know of two companies making PDP-11 performance upgrades, but I didn't think anyone still made such things for PDP-10s.
Thanks!
Eric
Re:Used a pdp-8? I built one!
on
PDP-10 Revival
·
· Score: 1
I'd like to find a used copy of that book. A search didn't turn up anything matching the author's names you've given; can you provide an exact title or other details about the book?
Doesn't include PDP-6 or PDP-10.
But it does simulate all the DEC 12-bit, 18-bit, and 16-bit machines. I've run RT11 and RSTS/E on the PDP-11 simulation.
The directory on the DEC FTP site is no longer maintained; the current simulator web page is
here.
Unlike C, there's absolutely *nothing* in Ada that requires a particular byte or word size, or requires two's-complement arithmetic. A 36-bit one's-complement machine poses no special challenge for Ada.
They only ran into trouble because (apparently) they wanted to use some or all of their C compiler as a back end.
Chapter 13 of the Ada LRM (Representation Specifications) allows an Ada programmer to define layouts of data types and structures down to the bit level if desired (typically when writing device drivers), but it is explicitly warned that such code is non-portable.
The last PDP10 that was actually being used was removed from service 3 years ago.
False. Al Kossow and I *personally* deinstalled one last October, which had been in active use in for school district administration until September. It's currently patiently waiting for me to win the IPO lottery so I can run it again.
When we unloaded the machine we were somewhat pressed for time, but Mike Cheponis managed to take a few
photos.
There's apparently another 2065 still running in a school district in or around Boston.
The various PDP-10 CPUs did have backplanes, but not in the sense of having a general-purpose bus that you could simply plug peripheral cards into.
For instance, the KL10 CPU backplane has about 54 slots, each of which is wired for a specific card.
You're probably thinking about the KA10, which operated asynchronously. This made debugging hardware problems easier, because if a pulse got lost the machine halted and you could examing the lights to see intimate details of what it was doing at the time.
By comparison, the KI10, KL10, and KS10 are more conventional synchronous designs. If a logic error occurs, they just keep chugging along. By the time anyone notices that something is wrong,
the exact conditions that caused it are long gone.
Just like your modern PC.
Can you look up the part number (probably EK-something or DEC-10-something) and date? I've
got the last version scanned on my
web site,
but it might be interesting to scan older ones for comparison.
The "fast registers" were optional on both the PDP-6 (166 processor) and the KA10. Reportedly no KA10s were ever shipped without the option.
Re:Still in use out there....
on
PDP-10 Revival
·
· Score: 3
she was telling me at one point about the PDP-10's they still used.
[...]
they liked them because they were very tolerant of temperature extremes.
Not likely to be a PDP-10, then. The PDP-10 CPUs were finicky and required cooling. And except for the KS10, they would take up about 30 square feet of floor space for the CPU alone (no memory or peripherals). And the CPU uses about 12 KW of electricity (more for the memory and peripherals).
Your friend was much more likely talking about a small PDP-11. Even the big PDP-11s (e.g., 11/70)
were not suited to running in extreme environmental conditions.
they're not called "PDP-10"'s, they're called "DEC-10"'s
The CPU is a PDP-10. Which came in several variants over the years, the KA10 (discrete transistors, 1968), the KI10 (TTL logic, 1972), the KL10 (ECL logic, 1975) and the KS10 (TTL and AMD 2900 bit slice, 1978).
The complete system is called a DECsystem-10 or a DECSYSTEM-20, depending on whether it ran TOPS-10 or TOPS-20.
I think it would only take one a couple of weeks to code up the PDP-10 architecture in VHDL and target an
FPGA.
Not bloody likely. All of the software simulators required well over a year of development time. And you're not going to convince me that implementing the same complexity in hardware (even with an HDL) is *easier* than in software.
If you want to give it a try, get the DECsystem-10/DECSYSTEM-20 Processor Reference Manual from my web site. Prove me wrong! Please!!
At the Consumer Electronics Show now wrapping up, Sony showed its first CDR-compatible DVD players.
FALSE. ALL early Sony DVD players, including the DVP-S7000 and DVP-S3000, supported CD-R media. To make that work, they included two separate lasers, one red and one infrared. Their marketing people have dubbed this feature "dual discrete pickup".
It is only recently that Sony has offered "cheap" DVD players that omit this feature.
They may have pulled the wool over some investor's eyes, but their white paper does not describe any new technology whatsoever. If they are to be believed, they've invented the revolutionary new technique of subroutines.
In general, it takes more bits of memory to implement a function on a Universal Turing Machine than on a conventional microprocessor. The point of the UTM wasn't that it was efficient, it was that it was a very simply machine that could compute anything that is computable. But not necessarily very quickly.
I hope the managers of the funds my 401k is invested in don't invest in companies like this; do they have experts to evaluate high-tech startups?
the kernel could be modified to make Plex86 API calls directly instead of forcing Plex86 to emulate forbidden operations.
If that's what you want, just run User Mode Linux. As much as I like Plex86, I don't see that it really brings any value to the table if you're willing to run code (like UML) that does not need any virtualization.
It's useful for a lot more than that. I run multiple copies of Linux and of FreeBSD all under Linux (currently using VMware). It's great for kernel and driver development, network testing (a virtual network with multiple virtual machines), and lots of other things.
The fact that it can run Windows tends to blind people to other uses.
I'm not convinced that domain names are public resources.
They are public resources in that ownership of them is only temporary (while you continue to pay registration fees). I strongly hope that the courts will eventually decide that registrants do own the domain name, subject to this limitation.
Which raises the question of who owns the domain name before it is registered, or after it ceases to be registered. Network Solutions claims that they own the expired domains that their customers have registered, but I'm really hoping that ICANN, the Commerce Department, or the courts will fix that.
Anyhow, back to the matter at hand. If the registrant owns the domain (even temporarily), then it is very important that the registration information be public. This is just like buying real estate. You can go down to the county courthouse and find out who owns any parcel of land in the county, and this is very important for resolving legal matters. Domains are not any different in that regard.
Everyone knew from the outset that the open-source Mozilla effort would contribute in a major way to the next commercial Netscape browser, even before AOL bought them. Anyone who thought that Netscape (and AOL) wouldn't do everything possible to capitalize on that is incredibly naive.
Instead of complaining about it, we should be glad that Netscape is still heavily supporting Mozilla development. So in fact, some of those dollars do go back into Mozilla.
I doubt we will ever
develop computers with the sophisticated power of even a mouse brain, although many may
protest that we already have exceeded their gross power. I believe that things like perception and reasoning are
beyond the scope of raw power.
If you're saying that just having enough raw power is insufficient, that's true. If you're saying that we won't be able develop computers matching the sophistication of biological brains (i.e., artificial intelligence), I think you're wrong.
I strongly suggest reading
The Age of Spiritual Machines: When Computer Exceed Human Intelligence by Ray Kurzweil. Also
Engines of Creation by K. Eric Drexler.
For a contrary opinion, you can read
The Emperor's New Mind by Roger Penrose. While it's well worth reading, Penrose's argument against artificial intelligence seems to be that intelligence requires quantum uncertainty, and that computers are deliberately designed to avoid the effects of quantum uncertainty.
This argument fails to pursuade me for two reasons:
Penrose fails to demonstrate a convincing need for quantum uncertainty
If quantum uncertainty does turn out to be necessary for intelligence, there's no reason why we can't build computers that are affected by it. They may not be much like today's computers, but that wouldn't make them any less artificial.
That argument might apply if it is scanning "itself". Because it's scanning another instance of VMware, which can be effectively halted whenever it is scanned, it doesn't apply. If VMware provided a true virtual machine, any program that runs on the real machine, including VMware, would run on it.
A client program that scans and modifies other programs within the virtual machine is no different than any other piece of self-modifying code, and VMware obviously supports that.
The conclusion is that VMware does not provide a full virtual machine. It's not clear exactly what they left out and why. Another evidence of this is that they require you to tell it what client OS you're running. Although they do offer a choice for "other". It would be very interesting to know what they do differently based on the client OS choice, but I imagine that they consider that information proprietary.
The x86 is not actually virtualizable (since
there are instructions which do different things
at user and supervisor level,
I'm fully aware of the difficulty in virtualizing the x86. Actually most of the instructions in question do the same thing at any ring, but as you say, the problem is that they don't trap. I was really hoping that AMD would add a mode bit in a control register that would serve to make the non-virtualizable instructions trap on the Athlon (or Sledgehammer), but apparently they don't view that as being a sufficient advantage to justify the relatively small development cost.
but it breaks down when the
program being run inside vmware does
something unusual like scanning its
own code for non-virtualizable
instructions.
There's no reason for it to "break down". Scanning code doesn't involve executing any special instructions that are both non-virtualizable and that VMware can't already handle.
If there really was some exotic x86 instruction sequence that VMware couldn't handle, it seems likely that one of the supported operating systems would have managed to use it.
Slashdot Mirror
When the VAX-11/780 was shipped in 1978, although it had a larger address space (512 MB physical, 2 GB virtual), the maximum amount of physical RAM it could be configured with was 2 MB. This limit was later raised, but it shows that of the PDP-10s and VAXen available in the same time frame, the PDP-10 was clearly superior in most regards.
The KL10 benchmarked at more than twice the performance of an VAX-11/780 on most workloads.
Pretty neat how the 1975 machine was a significant improvement on its 1978 "successor"!
In fact, the VAX-11/780 performance was so disappointing that they had to cancel the PDP-11/74 (four-processor SMP version of the 11/70), because it was expected to be much more cost-effective than the VAX.
You could equally well say that the PDP-10 was developed to support TOPS-10 and TOPS-20, and the VAX was not.
Thanks!
Eric
Thanks!
The directory on the DEC FTP site is no longer maintained; the current simulator web page is here.
They only ran into trouble because (apparently) they wanted to use some or all of their C compiler as a back end.
Chapter 13 of the Ada LRM (Representation Specifications) allows an Ada programmer to define layouts of data types and structures down to the bit level if desired (typically when writing device drivers), but it is explicitly warned that such code is non-portable.
When we unloaded the machine we were somewhat pressed for time, but Mike Cheponis managed to take a few photos.
There's apparently another 2065 still running in a school district in or around Boston.
You're probably thinking about the KA10, which operated asynchronously. This made debugging hardware problems easier, because if a pulse got lost the machine halted and you could examing the lights to see intimate details of what it was doing at the time.
By comparison, the KI10, KL10, and KS10 are more conventional synchronous designs. If a logic error occurs, they just keep chugging along. By the time anyone notices that something is wrong, the exact conditions that caused it are long gone. Just like your modern PC.
Can you look up the part number (probably EK-something or DEC-10-something) and date? I've got the last version scanned on my web site, but it might be interesting to scan older ones for comparison.
The "fast registers" were optional on both the PDP-6 (166 processor) and the KA10. Reportedly no KA10s were ever shipped without the option.
Your friend was much more likely talking about a small PDP-11. Even the big PDP-11s (e.g., 11/70) were not suited to running in extreme environmental conditions.
The complete system is called a DECsystem-10 or a DECSYSTEM-20, depending on whether it ran TOPS-10 or TOPS-20.
If you want to give it a try, get the DECsystem-10/DECSYSTEM-20 Processor Reference Manual from my web site. Prove me wrong! Please!!
It is only recently that Sony has offered "cheap" DVD players that omit this feature.
In general, it takes more bits of memory to implement a function on a Universal Turing Machine than on a conventional microprocessor. The point of the UTM wasn't that it was efficient, it was that it was a very simply machine that could compute anything that is computable. But not necessarily very quickly.
I hope the managers of the funds my 401k is invested in don't invest in companies like this; do they have experts to evaluate high-tech startups?
The fact that it can run Windows tends to blind people to other uses.
Which raises the question of who owns the domain name before it is registered, or after it ceases to be registered. Network Solutions claims that they own the expired domains that their customers have registered, but I'm really hoping that ICANN, the Commerce Department, or the courts will fix that.
Anyhow, back to the matter at hand. If the registrant owns the domain (even temporarily), then it is very important that the registration information be public. This is just like buying real estate. You can go down to the county courthouse and find out who owns any parcel of land in the county, and this is very important for resolving legal matters. Domains are not any different in that regard.
Instead of complaining about it, we should be glad that Netscape is still heavily supporting Mozilla development. So in fact, some of those dollars do go back into Mozilla.
For a contrary opinion, you can read The Emperor's New Mind by Roger Penrose. While it's well worth reading, Penrose's argument against artificial intelligence seems to be that intelligence requires quantum uncertainty, and that computers are deliberately designed to avoid the effects of quantum uncertainty.
This argument fails to pursuade me for two reasons:
Is this the height of arrogance or what? They turned an entire galaxy (two, in fact) upside down just because it looks nicer!
A client program that scans and modifies other programs within the virtual machine is no different than any other piece of self-modifying code, and VMware obviously supports that.
The conclusion is that VMware does not provide a full virtual machine. It's not clear exactly what they left out and why. Another evidence of this is that they require you to tell it what client OS you're running. Although they do offer a choice for "other". It would be very interesting to know what they do differently based on the client OS choice, but I imagine that they consider that information proprietary.
If there really was some exotic x86 instruction sequence that VMware couldn't handle, it seems likely that one of the supported operating systems would have managed to use it.