[Simh] Custom ROMs on PDP-11 sim

[Johnny Billquist]

On 2017-12-16 16:21, Timothe Litt wrote:
> On 16-Dec-17 07:35, Johnny Billquist wrote:
>> Top-posting to make it simple, while still keeping the original text.
>>
>> While it is true that device access might be done using relative 
>> addressing, that would in general be a bad software design. Things 
>> like device CSRs should never be accessed as relative addresses, but 
>> should be absolute. Any sane programmer should know that. And it is 
>> not any extra effort in doing this on a PDP-11, so the programmer have 
>> no real excuse for not doing it right. (But I know that people 
>> sometimes still do things wrong anyway.)
> 
> While this case is moot, dumping peripheral ROMs has come up before, so 
> correct information may be useful to someone in the future.

Indeed.

> I'm pretty sure that (among other things), I'm knowledgeable, sane and a 
> programmer.  I was not writing about "the general case".  This thread 
> was specifically about ROMs embedded in a peripheral.

Not trying to make any statements about you here.

>  This is a 
> different environment from the "general" case, and one where your 
> comments are off-base.  This is the exception to *never*.  It has 
> nothing to do with laziness or 'wrong'; I assumed neither.  And PIC is 
> only one aspect of the problem as presented.
> 
> It is true that in a typical OS driver, a CSR base is specified by an 
> absolute (if possibly mapped) address, with code like
> 
>      mov #173100, r0 ; or
>      mov csrbase(R5), r0 ; where r5 points to some data structure, and 
> csrbase contains an absolute I/O address
>      bit    #100, 4(r0)
> 
> This ensures that the *code* can be moved; *the device is at some fixed 
> address* determined by SYSGEN, autoconfiguration, or the like.  So the 
> references are register deferred and/or indexed relative to an 
> "absolute" address.  The code should be PIC, as most (later) OSs want to 
> be able to dynamically load drivers.  I'd agree that in this case, PIC 
> with an absolute device address is the preferred (and sometimes 
> required) implementation.
> 
> In the specific case of a device ROM, CSR access would indeed be 
> properly done with relative addressing.  There isn't much (sane) 
> choice.  Calling it 'bad software design' is inappropriate, and 
> overlooks the environmental constraints and functional requirements of a 
> device ROM.

Fair enough. If you actually have a device which includes both CSR and 
code, that are moved together through I/O space, then yes you'd want to 
use relative addressing for the CSR.

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

But with the limited space in the I/O page, you would not want to have 
the same code replicated all over the space.

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.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol