>Tony Duell wrote:
> In one sense it is. It would be possible to modify a PDP11 and add (say)
> transcendental functions (SIN, COS, TAN, etc) to the floating point
> coprocessor (yes, I do realise this is not at all a trivial modification,
> but it's certainly possible). But the result would probably not be called
> a PDP11. Certainly if I modified a PDP11 to have 32 bit registers and
> ALU, then the result wouldn't be a PDP11.
Jerome Fine replies:
The answer I am giving is NOT practical in general, but for specific cases
can be helpful.
First, I was not ever suggesting that the basic underlying hardware registers
be modified when I mentioned 32/64 bit integer arithmetic. Rather that
existing registers/memory be used in a manner which could still hold the
32/64 bit results - and then the only change would be that a single instruction
within the "PDP-11" code be used to replace multiple instructions. Exactly
the same thing could be done within a current "real" PDP-11 to implement
what "seems" to be that capability as is done with "impaired" PDP-11 CPUs
such as an 11/03 which do NOT implement some of the instructions that
more intelligent CPUs have such as the 11/23 or the 11/73. In that case,
a TRAP SUBROUTINE handles the missing instruction and it is emulated,
at of course an even higher overhead as opposed to inline code or a normal
subroutine call.
That approach with a "real" PDP-11 IS worth while when the feature is
used extensively since even calling a subroutine has overhead. The saving
over inline code is often worth the extra overhead.
HOWEVER, when an emulator is being used, it is possible to "implement"
a different solution. Rather than using a TRAP SUBROUTINE, it is
possible to actually have our cake and eat it at the same time. The
emulator can be "instructed" to recognize the "new instruction" and because
that level of implementation is MUCH more efficient and much faster,
there is much more benefit.
I could provide other examples, but this one is simple and clear-cut.
Either the method is acceptable or it is not. The key is that ONLY
what a TRAP SUBROUTINE can do is allowed - nothing more.
> But I feel the same restriction applies to emulators too. A PDP11
> emulator has to do what a real PDP11 would do. If you start adding extra
> instructions, then it's no longer emulating a PDP11. It's emulating an
> enhanced processor that was based on the PDP11. Which is exactly what
> hardware mods would give you.
I agree. But I still suggest that under an emulator, the approach I
am suggesting can often be useful. I agree that it would need to be
backed up with the equivalent code that a TRAP SUBROUTINE
would use with real PDP-11 systems.
> Tobe honest, it would probably be easier to make a new processor from
> scratch if you wanted to do something like this to the hardware. Just as,
> I susepct, if you wanted to design an emulator for a ficticious
> processor, then you wouls wnt to start by designing a clean, orthogonal,
> instruction set. But it would be possible to start from an existing
> 'machine' in either case.
Now that seems interesting - at least for hardware. Is it relatively
that easy these days to implement a PDP-11 instruction set and all
the interrupts? I know that at least two companies have done that.
QED is one and Osprey might be another.
> > In addition, I don't consider that limitation when I am dealing
> > with an emulator. I have asked John Wilson to modify E11
> > to allow a number of items:
> > (a) Be able to identify E11 via a PDP-11 instruction
> OK, that's reasonable, because you could identify some later models of
> PDP11 in that way IIRC.
YES! There is an instruction which puts the model number in R0.
> > (b) Add 32 bit integer arithmetic - at least add and subtract
> > (c) Add 64 bit integer arithmetic - at least add and subtract
> But no real PDP11 has those instructions. So if you add them to a PDP11
> emulator, then the result is no longer a PDP11 emulator, in that there is
> a sequence of instructions that behaves differently on the PDP11 and the
> emulator. Just as if you wire up a 32 bit ALU and registers to a PDP11
> processor board, the resulting machine is no longer a true PDP11.
Well I don't completely agree. The FPU on the 11/73 may allow
for not only faster implementation of floating point instructions, but also
for extra instructions. Just as the CIS instruction set is done. PLUS,
the 11/44 has something called WCS - if I remember correctly. I
suspect that a "true" or real PDP-11 is not completely defined.
In addition, it should (I have no idea if it is easy or even practicable)
be possible to allow extra instructions by adding extra hardware
that is just an extra board.
I agree that all of the above is totally academic unless I have the
opportunity to work with either SIMH code or have the information
about the interface required by Ersatz-11 since I will NEVER be
doing this in hardware.
> > In addition, there already is the capability to add a "dll" (don't
> > ask me exactly how is is done - and it is ONLY for the FULL
> > version) which is able to directly access the memory of the PC
> > via "emulated hardware registers" (addresses in the I/O page)
> > using PDP-11 instructions. Doing that with a real PDP-11
> > would probably be very easy these days - just add a board
> > that contains the required hardware - and with memory so
> > inexpensive, it could use the same memory chips that the PC
> > uses.
> There have been all sorts of interefaces proposed and made over the years
> to let one computer have access to the memory of another. People have
> designed cards that appear as I/O ports to the 'master' system and act
> as proper bus master on the other side (so they can request the bus from
> another genuine processor on, say, a VME bus and then access the memory
> and peripherals over there). Simpler ones just insist on being the only
> master on the 'slave' side -- there have been many attempts to add ISA
> slots to other machines in this way to allow the use of cheap ISA I/O
> cards, for example.
Well, for the PDP-11 Qbus systems, a IDE controller has been proposed
that would emulate MSCP just like the CMD host adapters do with SCSI
drives. In addition, there are co-processors available that can do vector
instructions and place the results in shared Qbus memory. One board I
did work with was called a SKYMNK. It did FFTs and other such stuff
like vector arithmetic.
> > > I guess that with software there are 2 main things you can do (apart from
> > > use it!). You can fix origianl bugs. Or you can modify it to do
> > > something (slightly?) different.
> > Or even something very different, especially to add code which can
> > do something very different.
> That tends to get called 'doing a total redesign' when it's done to
> hardware :-)
I agree with you there as well as far a hardware is concerned. But
with software, such changes tend to get done MUCH more gradually.
Many bugs can be fixed with only one instruction and most require
only a few instructions. In software, the primary effort is to identify
the bug - correcting it is often almost trivial.
Adding a few features rarely requires a redesign.
I suspect that in hardware, finding the bug is ONLY the first step.
And while in some cases changing the firmware is a simple solution
and only an EPROM needs an update (these days only a EEPROM),
if actual hardware needs to be changed, I guess you fellows who
are capable with a soldering iron don't have too much of a problem.
> > As for your last example, I think that a bug that is in the RT-11
> > operating system (been there for almost 20 years) could also be
> > equivalent to the hardware difficulty you mention. In this case,
> Not really. The software bug was always there. It was a design defect
> really. We have those in hardware too, and some of them occur _very_
> infrequently.
In many respects, I agree that hardware and software are very
similar.
> But software doesn't fail with time (OK, the media it's stored on can
> fail, but then you can restore from a backup and have a perfect copy
> again). If something worked right once, then it will always work right.
> If there's a design bug, then that bug will be there until it's cured.
And if the programmer tells the program to do the wrong thing,
then the computer will do that as well - and every time. A long time
ago, the definition I was told of a computer (A SPEEDY MORON)
does not seem to have changed.
> This is not true of hardware. You can have a circuit which was correctly
> designed, and which worked perfectly for 10 years (say). And then a
> component fails. It stops working. You have to find that faulty component
> and replace it.
That does seem to be the one big difference. While hardware can be
built to detect its own failures, presently that is very unusual.
> The differece (at the hardware level) between the 2 sorts of bugs is
> really that in the first case all the components are still what they
> claim to be. A resistor with brown, black, orange bands is still a 10k
> resistor. A 2N3904 transistor is still an NPN transistor meeting the
> characteristics given in the data sheet. A 74LS00 is still a quad 2-input
> NAND gate. It's just that the way they are connected together produces a
> circuit that doesn't do what the designer intended. That's a design bug.
Very similar in software.
> In the second case you'll find things like a 2N3904 transistor that's
> open-circuit base-emitter, and which is therefore not a transistor at
> all. Or a 10uF capacitor that behaves as though it has a 100 ohm resistor
> in series with it, inside the can (this is what's mean by ESR --
> effective series resistance). The components are not what they claim to
> be any more. If you rebuilt this cirucit with known-good components then
> it would behave as originally intended. I really can't think of a
> software equivalent of this.
But that is why there is a difference between hardware and software,
just as you stated above. You are entirely correct.
> > In that aspect, such intermittent problems are the most difficult
> > to trace and find the cause.
> That is certainly true of hardware problems also. Faults that 'stay put'
> when you are looking for them are much easier to find :-)
More to the point, if it is possible to discover what triggers the
fault and repeat the trigger successfully, then with software my
personal experience is that 95% of the time, maybe even 99%
of the time the solution is extremely simple, often as little as
a few instructions, sometimes even one instruction. It can take
as short a time as a few seconds to fix - and often the actual
documentation as the what was done takes much longer. I
could provide a number of examples, but individual examples
don't show anything - it is the average that counts.
But I am totally unable to solve hardware problems, so it would
be interesting to know how long the average hardware fix takes?
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
Received on Mon Aug 12 2002 - 20:10:00 BST