[Simh] FW: pdp 11 timing -->anf10 workstation on pdp11 with throttling

Timothe Litt litt at ieee.org
Mon Jul 20 19:03:48 EDT 2020


> Well, then the first question that needs to be answered, which model
> of PDP-11 was that code expected to run on

ANF-10 primarily runs on the 11/40 (well, and the PDP-10s).  Exceptions:
DN200 remote station: 11/34, DN22: 11/04 .

CHK11 compiles accordingly.

On 20-Jul-20 18:19, Johnny Billquist wrote:
> Well, then the first question that needs to be answered, which model
> of PDP-11 was that code expected to run on, because the results will
> differ depending on that. Also, what kind of memory? (I would guess
> some old, small core memory boards.)
> The PDP-11 execution speed really does vary based on many factors, on
> real hardware...
>
>   Johnny
>
> On 2020-07-21 00:13, simh at swabhawat.com wrote:
>>
>>
>> L.S.
>>
>> Actually where this is important, is when using Pdp11 based ANF10
>> workstations in the Tops10 realm.
>>
>> When starting up, the Anf10 software on the pdp11 sim test various
>> devices for functionality thereby using instruction count based loops
>> etc.
>> When all the devices necessary (paper tape reader/punch, incremental
>> plotter interface, DZ and DH multiplexors, DMS and DUP/KDP devices
>> and DL11 interfaces) are properly verified, it cranks up the
>> communication configuration with  scanning the network for active
>> Pdp10 Tops10 host systems.
>> The throttling of the pdp11 should be carefully selected to let this
>> function.
>>
>>
>> Reindert
>>
>>
>> -----Original Message-----
>> From: Simh [mailto:simh-bounces at trailing-edge.com] On Behalf Of
>> Johnny Billquist
>> Sent: Monday, 20 July, 2020 23:20
>> To: Paul Moore <paulmoore100 at hotmail.com>; simh at trailing-edge.com
>> Subject: Re: [Simh] pdp 11 timing
>>
>> Instruction timing as such is not relevant. Different implementations
>> had very different timings, not to mention that speed of memory also
>> makes a difference.
>>
>> Devices basically do not have a strict timing either, but yes, there
>> is plenty of software that assumes that an interrupt does not happen
>> before a single instruction have been executed after the previous
>> interrupt, from the same device, for example.
>> On real hardware that was just an absurd case that lots of code never
>> considered, since it wasn't really physically possible for it to happen.
>>
>> The throttling in simh is because some people want the emulation to
>> somewhat mimic the real thing. For some people, that experience of
>> slowness is desirable.
>>
>>     Johnny
>>
>> On 2020-07-20 23:10, Paul Moore wrote:
>>> (I am writing my own emulator just because I have never done that
>>> before, and the PDP 11 is such a pivotal system in the history of
>>> modern computing it seemed worth learning about, and what better way
>>> to learn than to emulate it )
>>>
>>> So how important is timing of instruction execution and device
>>> response?
>>>
>>> The PDP 11 docs go  to great length giving instruction timing. But the
>>> fact that there is a % throttle in simh suggest that’s not important.
>>> I assume that turning that throttle up and down makes the emulated CPU
>>> go faster and slower. I have seen code using simple counters as delays
>>> but I assume that if you want precision you use the Kw11.
>>>
>>> With regards device responses I have found that going ’too fast’
>>> upsets code. If they do something that triggers an interrupt (set ‘go’
>>> for
>>> example) and the interrupt arrives too soon (like before the next
>>> instruction) they get surprised and can misbehave (you could argue
>>> that’s a bug, but that’s irrelevant). So always wait a few beats. But
>>> I assume there is no reason to try to precisely emulate the timing of
>>> , say, a disk drive. (The early handbooks state how awesome the async
>>> nature of the IO subsystem is cos you can swap out old for new and
>>> things just go faster).
>>>
>>>
>>> _______________________________________________
>>> Simh mailing list
>>> Simh at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20200720/4baeb9a0/attachment.html>


More information about the Simh mailing list