On 2017-12-16 23:32, Timothe Litt wrote:

On 16-Dec-17 16:38, Johnny Billquist wrote:

However, such a device would be wrong to start with. And I've never seen anyone do that, but sure, it could be done.

Read the OP.  He has such a device.  It has ROMs with PDP-11 code -- or at least, that's his assumption.  And it's a Unimate robot controller. If that assumption is correct, it fits the architecture that I described.

No, you are making several assumptions here.
First of all, there is nothing saying that it even works if you have several devices. Second, we do not know if it can be at different addresses. Third, even though you have ROMs on it, there is nothing that says that those are even exposed to the PDP-11. Fourth, what was often done was that if you had PDP-11 code available on the card, it was separately enabled compared to the CSRs as such, and if the memory was enabled, it was located at a fixed address in I/O space (several examples of such controllers exist). Fifth, another solution some controllers applied was that the code would be DMAd from ROMs into PDP-11 ram, and then executed from there, and that was only used for diagnostics and configuration stuff (see most SCSI controllers for example). Point 4 and 5 have lots of previous art, and those are the only ones I know of which present any PDP-11 code, and those do not use the scheme you are suggesting, but do use absolute addresses for CSRs in the PDP-11 code. For the SCSI controllers, you interactively have to tell which CSR the code should access, and for some other controllers, they have the code at a fixed address, for booting, and only support booting from the controller at a fixed CSR address.

But with the limited space in the I/O page, you would not want to have the same code replicated all over the space.
It depends.  If I were an OEM, and I anticipated a small number of my devices per CPU, this would be a good way to avoid having a separate ROM module.  Robots costing $100Ks fit that bill.

Further, the typical code isn't very large.  For example, the M9301-YA, 512 words - in I/O space, can bootstrap 8 different devices AND has 7 CPU self-tests and a memory test.  The -YB has a console emulator, self-tests, and 11 device bootstraps.

Yes. And these bootstraps are very tight, and only works on fixed CSR addresses.

So it's quite plausible to have a host-run self-test, bootstrap, calibration, or other code on- board without consuming unreasonable amounts of I/O space.

If you repeat those 512 word on each card, you'll run out of I/O space after 6 cards (at best). Add any other devices, and you hit trouble even earlier.

There are other schemes to avoid duplication, but I'll leave those as an exercise for the reader.

Any scheme will by necessity have you not repeat the same code and memory use on each card.

So in the end no, I do not believe that it would ever be the right thing to have relative addressing for CSRs. Your example is valid in that such a design would make sense to have relative addressing, but such a device is already a wrong thing to start with, and should not be.

You don't get to decide and enforce what is right/wrong or what should not be.  As a system architect, I had some power to ordain what should be.  But one quickly discovers that even that power is limited.  You can have an opinion, but sometimes reality butts in. Your idea of architectural purity and/or design constraints will be tested (and changed) by Manufacturing, OEMs, customers, and the field - which have their own challenges.

It is unwise to assume that you know enough to say "never" or "always". Unless you like being proven wrong.

I certainly do not get to decide right or wrong.

The rest we can continue argue, if you want to.

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: b...@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Reply via email to