<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 16-Dec-17 16:38, Johnny Billquist
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3fe5e939-192b-bc34-858b-b70083a3b72e@softjar.se"><br>
However, such a device would be wrong to start with. And I've
never seen anyone do that, but sure, it could be done.
<br>
<br>
</blockquote>
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.<br>
<br>
<blockquote type="cite"
cite="mid:3fe5e939-192b-bc34-858b-b70083a3b72e@softjar.se">But
with the limited space in the I/O page, you would not want to have
the same code replicated all over the space.
<br>
</blockquote>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
There are other schemes to avoid duplication, but I'll leave those
as an exercise for the reader.<br>
<br>
<blockquote type="cite"
cite="mid:3fe5e939-192b-bc34-858b-b70083a3b72e@softjar.se">
<br>
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.
<br>
<br>
</blockquote>
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.<br>
<br>
It is unwise to assume that you know enough to say "never" or
"always". Unless you like being proven wrong.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:3fe5e939-192b-bc34-858b-b70083a3b72e@softjar.se"> Johnny
<br>
<br>
</blockquote>
<br>
<br>
</body>
</html>