🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: alt.sys.pdp8
Article #47

Re: PC incrementing

#47
From: Charles Lasner
Date: Tue, 13 Oct 1992 19:28
48 lines
2974 bytes
In article <_byz88_@rpi.edu> jwilson@unix.cie.rpi.edu (John Wilson) writes:
>I'm sure someone (cjl?) will know the answer to this nitpicky
>question...
>
>When an MRI occurs in the last word of a page (+177) and has bit
>4 set ("this page" as opposed to page 0), is the datum accessed
>on this page or the next one?  That is to say, by the time the
>high 5 bits of the PC have been prepended to the low 7 bits of
>the instruction, has the PC been incremented yet?
>
>I would just try it but my 8/e is in Boston...
>
>Thanks,   John

Real easy.  Look at the register flow:

First update PC to fetch your instruction at say 0377.  It goes into the
memory buffer.  Then the PC is updated to 0400.  Note that if an ISZ and
it skips, that could make it 0401, but in any case the PC is out of the loop.
The effective address is calculated from the MB, not the PC's pointings at
that point.  Moreover, the MB can be uses as a pointer as well, and even
an autoindexed one in the case of indirect through what (was) in 0010-0017
before writing that location back.  In any case, eventually the effective
address is calculated and put into the memory address, since the MA is
where the memory comes from, not the PC.  (Yes, earlier the PC -> MA was
performed to fetch the instruction from memory.)

So, the answer is that there is no special relationship with falling through
a page.  The page where the instruction is stored is the current page for
all effective address calculation purposes.

An alternate comment:  The PDP-8/e panel is an economy measure, and doesn't
really tell what's going on.  The earlier machines make it clear in the lights
what's in what when and where.  Some of the confusion is clearly caused by
always reading a bunch of lights merely labeled "memory address" without
regard to whose address it is at the moment, etc.

An interesting side note for simulators:

There have been -8 simulators written that aren't compatible on a similar
point: falling off the end of a field, not a page.  Regardless of instruction
type, some programs do the un-PDP-8-ly thing of going to the next FIELD,
not to location 0000 of the current field.  Of course little software,
even diagnostics, ever check for this!  (Although I did once write a piece
of bootstrap-time once-only code in a particular handler that needed this
to work right!  Thus, a simulator with that peripheral in it would flunk :-).)

cjl
Technical Details
Message-ID: <1992Oct13.192851.5504@news.columbia.edu>
Path: arc1-ca.pugleaf.net!sparky!uunet!stanford.edu!rutgers!news.columbia.edu!watsun.cc.columbia.edu!lasner
References: <_byz88_@rpi.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!stanford.edu!rutgers!news.columbia.edu!watsun.cc.columbia.edu!lasner
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: PC incrementing
Message-ID: <1992Oct13.192851.5504@news.columbia.edu>
Date: 13 Oct 92 19:28:51 GMT
References: <_byz88_@rpi.edu>
Sender: usenet@news.columbia.edu (The Network News)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Lines: 48
Nntp-Posting-Host: watsun.cc.columbia.edu