1
0
mirror of https://github.com/wfjm/w11.git synced 2026-03-10 04:54:26 +00:00

update known_differences and other md's [skip ci]

This commit is contained in:
wfjm
2022-09-08 08:49:37 +02:00
parent 137889a271
commit fe5cb6d757
7 changed files with 115 additions and 25 deletions

View File

@@ -40,7 +40,7 @@ The full set of tests is only run for tagged releases.
- added dasm-11, a PDP-11 disassembler
### New features
- new verification codes
- tools/mcode: added memclr.mac (writes zero into memory)
- tools/sys/mcode: added memclr.mac (writes zero into memory)
- tools/tcode: fast cpu verification codes
- tools/tests: test programs
- tools/bin: added dasm-11, a PDP-11 disassembler

View File

@@ -51,6 +51,17 @@ Further analysis
- pm has the logic to set it from cm in vector pushes
- but in the RTT/RTI update case, pm is handled like cm and reset
And EK-KB11C-TM-001_1170procMan.pdf page 223 has the clear statememt
> After executing the User program's request, the Kernel program returns
> control to the User program by an RTI. Before doing this, the Kernel
> program ensures that both current and previous mode bits are set to User.
> If this were not done, the User program could read the Kernel proprietary
> code via the MFPI.
So it's the sole responsibility of the software to set `pmode` properly.
### Fixes
Simply remove the extra term, now
```

View File

@@ -2,6 +2,41 @@
The case id indicates the release when the issue was first recognized.
### V0.791-3 {[issue #35](https://github.com/wfjm/w11/issues/35)} -- MMU: D space used instead of I space for PC deferred specifiers
Test 072 of `ekbee1` fails with
```
D-SPACE ENABLE CIRCUITRY HAS FAILED
ERROR AUTOI/D VIRTUAL
REGISTR REGISTR ADDRESS TESTNO PC AT ABORT
100027 000000 060410 000072 060412
100027 000027 060416 000072 060422
```
The test does
```
060410: tst (pc)
060416: cmp #240,(pc)
```
and expects that these accesses are done to I space.
They are done to D space instead.
The w11 uses D space only for `(pc)+` and `@(pc)+` specifiers.
Clearly a bug.
Wasn't detected so far because this access mode has no practical value
and this therefore not used in normal software.
### V0.791-2 {[issue #34](https://github.com/wfjm/w11/issues/34)} -- MMU: ACF=1 traps on any access
Test 055 of `ekbee1` fails with
```
MEMORY MANAGEMENT TRAP OR ABORT HAD INCORRECT CONDITION
EXPECTD ERROR AUTOI/D VIRTUAL
CONDITN REGISTR REGISTR ADDRESS TESTNO PC AT ABORT
020011 030011 013427 054032 000055 054040
```
This is caused by a bug in pdp11_mmu. For ACF=1 a trap is taken for any access,
it should be taken only for read accesses.
### V0.791-1 {[issue #33](https://github.com/wfjm/w11/issues/33)} -- MMU: PDR A bit is set for every access
The `PDR` `A` bit is described in the Technical Manual as
@@ -126,30 +161,6 @@ in the J11, it is not used by common operating systems.
Therefore this is considered a to be a minor deficit. Will be fixed in an
upcoming release.
### V0.50-4 {[issue #24](https://github.com/wfjm/w11/issues/24)} -- CPU: src+dst deltas summed in mmr1 if register identical
Test 12 of maindec `ekbee1` fails because it expects after a
```
mov #100000,@#mmr0
```
which sets an error bit in `mmr0` and thus freezes `mmr0`, that `mmr1` contains
```
013427 (00010 111 00010 111) (+2,r7;+2,r7)
```
while w11a gives
```
000047 (00000 000 00100 111) (--,--;+4,r7)
```
The `mmr1` content is _different_ compared to the original 11/70 behavior,
but is _logically correct_, fault recovery in OS (like in 211bsd) will work
correctly. Therefore this is considered a to be a _minor deficit_.
The 11/70 documentation clearly states that there is an additional state bit
that counts the write accesses to `mmr1`. This ensures that each of the two
logged accesses end in separate bytes (byte 0 filled first).
The w11a only uses byte 1 when the register number differs.
### V0.50-1 {[issue #23](https://github.com/wfjm/w11/issues/23)} -- CPU: several deficits in trap logic
The current w11a implementation has several deficits in the handling of
@@ -241,6 +252,33 @@ free}_
## Resolved Issues
### V0.50-4 {[issue #24](https://github.com/wfjm/w11/issues/24)} -- CPU: src+dst deltas summed in mmr1 if register identical
Test 12 of maindec `ekbee1` fails because it expects after a
```
mov #100000,@#mmr0
```
which sets an error bit in `mmr0` and thus freezes `mmr0`, that `mmr1` contains
```
013427 (00010 111 00010 111) (+2,r7;+2,r7)
```
while w11a gives
```
000047 (00000 000 00100 111) (--,--;+4,r7)
```
The `mmr1` content is _different_ compared to the original 11/70 behavior,
but is _logically correct_, fault recovery in OS (like in 211bsd) will work
correctly. Therefore this is considered a to be a _minor deficit_.
The 11/70 documentation clearly states that there is an additional state bit
that counts the write accesses to `mmr1`. This ensures that each of the two
logged accesses end in separate bytes (byte 0 filled first).
The w11a only uses byte 1 when the register number differs.
Fixed with commit [3bd23c9](https://github.com/wfjm/w11/commit/3bd23c9),
see [ECO-032](ECO-032-MMR1_fix.md).
### V0.79-1 {[issue #29](https://github.com/wfjm/w11/issues/29)} -- migrate from Travis to GitHub actions
#### Original Issue

View File

@@ -24,6 +24,11 @@ So the modified `sp` is stored.
The w11 implement ion first reads `sp` into a register, then decrements
`sp` and writes. So the original `sp` is stored.
EK-KB11C-TM-001_1170procMan.pdf clearly decribes the 11/70 behavior as
> JSR.10: ... and loads the DR with the contents of the general register 6.
> JSR.20: decrements SP by 2, new value is stored inb the SP and the DR for
> use in the external data transfer started on JSR.30
`jsr sp` is never used due to its bizarre semantics. The matching `rts sp`
results in a useless `sp` too. Given that, this is considered an
acceptable deviation from 11/70 behavior.

View File

@@ -0,0 +1,13 @@
## Known differences between w11a and KB11-C (11/70)
### MMU traps not suppressed when MMU register accessed
The 11/70 does not execute an MMU trap when an MMU register is accessed,
thus `MMR0` to `MMR3` and any of the `PDR` and `PAR` registers.
This causes test 061 of `ekbee1` to fail.
The w11 doesn't implement this trap suppression (neither does SimH).
Since MMU traps are a 11/70,11/45 only feature no OS uses them.
Given that, this is considered an acceptable deviation from 11/70 behavior.

View File

@@ -0,0 +1,14 @@
## Known differences between w11a and a SimH 11/70
### SimH: implicit stack pops not recorded in MMR1
The MMU abort behavior for instructions with implicit stack pops
(`RTS`, `MTPI`, `MTPD`) differs on SimH from w11 and a real 11/70.
SimH updates the stack pointer _after_ the stack value has been
read. If this read is aborted by the MMU, the state is `SP` unchanged
and `MMR1` zero. w11 and a real 11/70 update `SP` and record that in
`MMR1` before the stack value is accessed and an MMU abort detected.
In both cases the register change state and the `MMR1` state
are consistent, so MMU vector 250 handlers will work correctly.
This difference is only detected in test codes.

View File

@@ -10,6 +10,7 @@ The issues of the w11 CPU and systems are listed in a separate document
- ['instruction completed flag' in `MMR0` is not implemented](w11a_diff_70_instruction_complete.md)
- [`jsr sp` pushes original `sp` value](w11a_diff_70_jsr_sp.md)
- [18-bit UNIBUS address space not mapped](w11a_diff_70_unibus_mapping.md)
- [MMU traps not suppressed when MMU register accessed](w11a_diff_70_mmu_trap_suppression.md)
All points relate to very 11/70 specific behavior, no operating system
depends on them, therefore they are considered acceptable implementation
@@ -36,3 +37,11 @@ this is considered as an acceptable implementation difference.
to a timeout, again mostly in test programs.
**--> a 'watch dog' mechanism will be added in a future version which
suspends the CPU when the server doesn't respond fast enough.**
### Known differences between w11a and a SimH 11/70
The SimH emulator models only behavior what is relevant for the normal
operation of operating systems and user code. Many details which do not
have impact on normal operation are not modeled for performance reasons.
Test codes are sometimes sensitive to those details, that's why the most
relevant are listed here.
- [SimH: implicit stack pops not recorded in MMR1](w11a_diff_simh_mmr1_rts_mtp.md)