CAC 2015-08-22

tss

Did this massive rewrite of fault handling, and MR12.3 install, SVE setup, and MR12.5 upgrade all ran without problem.

Blink.

Okay; passes the regression tests.

Checking bugs:

map355? Odd; something changed…

r 07:56 0.042 0

cp >ldd>mcs>s>dia_man.map355
r 07:56 4.437 185

map355 dia_man.map355
MAP355
gcos_error_: A fatal error has occured.  The current job is being terminated.
line from >udd>se>Anthony>dia_man.map355 contains an illegal character in col. 
\c1
\014

Aborting GCOS job.
gcos_sysprint(10.0): Entry not found.
Cannot attach input stream gcos_sysprint_input_:
>pdd>!BLLBkGjbBBBBBB>dia_man.glist_
map355: Entry not found. checking for error messages in listing file.

alm -list? Fixed!

pascal run? Nope.

bce go? Fixed!

tape_archive? Not fixed.

Reverted the source code; map355 still off-script.

Meh

Not 'cp', but:

 ac x >ldd>mcs>s>mcs.s dia_man.map355

map355? better

MAP355

Error:  Fixed point overflow by gcos_slave_area_seg|25677 (in process dir)  (fi
\cxedoverflow condition)
f9-overflow/underflow
map355: can't find assembly error count message
map355: There was an attempt to use an invalid segment number. Calling tssi_$fi
\cnish_segment.
[[/cdoe]]

Running DBGBAR trace on the map355 to see if the problem jumps out...

[[code]]
map355 dia_man
MAP355
i8-run time exhausted
i8-run time exhausted
gcos_sysprint(10.0): Entry not found.
Cannot attach input stream gcos_sysprint_input_:
>pdd>!BLLBkJFbBBBBBB>dia_man.glist_
map355: Entry not found. checking for error messages in listing file.
map355: Incorrect access on entry. Calling tssi_$finish_segment.
[[/code]]

Oops.

Reduced to just trace:

[[code]]
map355 dia_man
MAP355
i8-run time exhausted
map355: can't find assembly error count message
map355: Incorrect access on entry. Calling tssi_$finish_segment.

$ grep TRACE tss.log | wc -l
2914257
[[/code]]

Try switching to a shorter map355 module...

[[code]]
map355 sim_tables
MAP355

Error:  Fixed point overflow by gcos_slave_area_seg|25677 (in process dir)  (fi
\cxedoverflow condition)
f9-overflow/underflow

$ grep TRACE tss.log | wc -l
2196680

[[/code]]

Okay!

[[code]]
DBG(535298981)> CPU TRACE: 00334:000000|015750 4 016463630000 (RET 016463) 016463 630(0) 0 0 0 00
DBG(535298983)> CPU TRACE: 00334:000000|002507 4 002513710000 (TRA 002513) 002513 710(0) 0 0 0 00
DBG(535298985)> CPU TRACE: 00334:000000|002513 4 005356234000 (SZN 005356) 005356 234(0) 0 0 0 00
DBG(535298987)> CPU TRACE: 00334:000000|002514 4 002525600000 (TZE 002525) 002525 600(0) 0 0 0 00
DBG(535298989)> CPU TRACE: 00334:000000|002525 4 000007001000 (MME 000007) 000007 001(0) 0 0 0 00
[[/code]]

Hmm. That's not really indicative of overflow; probably an exit handler...

Now, earlier in the code, this really jumps out:

[[code]]
DBG(534383195)> CPU TRACE: 00334:000000|025676 4 054200520201 (RPT 054200,AU) 054200 520(0) 0 1 0 01^M

DBG(534383197)> CPU TRACE: 00334:000000|025677 4 011412071011 (AWCA 011412,1) 011412 071(0) 0 0 0 11^M
DBG(534383197)> CPU TRACE: RPT/RPD first 1 rpt 1 rd 0 e/o 1 X0 054200 a 0 b 0^M
DBG(534383197)> CPU TRACE: RPT/RPD CA 011412^M
DBG(534383197)> CPU TRACE: rpt/rd repeat first; offset is 011412^M
DBG(534383197)> CPU TRACE: rpt/rd repeat first; X1 was 000000^M
DBG(534383197)> CPU TRACE: rpt/rd repeat first; X1 now 011412^M
DBG(534383197)> CPU TRACE: RPT/RPD delta first 0 rf 0 rpt 1 rd 0 e/o 1 X0 054200 a 0 b 0 xN 1^M
DBG(534383197)> CPU TRACE: RPT/RPD delta; X1 now 011413^M
DBG(534383197)> CPU TRACE: tally 21^M
DBG(534383197)> CPU TRACE: not tally runout^M
DBG(534383197)> CPU TRACE: not terminate^M

DBG(534383199)> CPU TRACE: 00334:000000|025677 4 011412071011 (AWCA 011412,1) 011412 071(0) 0 0 0 11^M
DBG(534383199)> CPU TRACE: RPT/RPD first 0 rpt 1 rd 0 e/o 1 X0 052200 a 0 b 0^M
DBG(534383199)> CPU TRACE: RPT/RPD CA 011412^M

DBG(534383201)> CPU TRACE: 025677 000532657220 (SCU 000532,N*) 000532 657(0) 0 1 1 00^M
[[/code]] 

[[code]]
        case 0071:   ///< awca
            /// If carry indicator OFF, then C(A) + C(Y) -> C(A)
            /// If carry indicator ON, then C(A) + C(Y) + 1 -> C(A)
            if (TSTF(cu.IR, I_CARRY))
                rA = AddSub36b('+', true, rA, 1, I_ZERO|I_NEG|I_OFLOW|I_CARRY, &cu.IR);
            rA = AddSub36b('+', true, rA, CY, I_ZERO|I_NEG|I_OFLOW|I_CARRY, &cu.IR);

            break;
[[/code]]

Leading up to the fault:

[[code]]
DBG(502162211)> CPU TRACE: 00334:000000|025676 4 054200520201 (RPT 054200,AU) 054200 520(0) 0 1 0 01
[[/code]]

C is one, so C(inst)0,17 -> C(X0).

[[code]]
X[0]=054200
[[/code]]

[[code]]
DBG(502162213)> CPU TRACE: 00334:000000|025677 4 011412071011 (AWCA 011412,1) 011412 071(0) 0 0 0 11
DBG(502162213)> CPU TRACE: RPT/RPD first 1 rpt 1 rd 0 e/o 1 X0 054200 a 0 b 0
DBG(502162213)> CPU TRACE: RPT/RPD CA 011412
DBG(502162213)> CPU TRACE: rpt/rd repeat first; offset is 011412
DBG(502162213)> CPU TRACE: rpt/rd repeat first; X1 was 000000
DBG(502162213)> CPU TRACE: rpt/rd repeat first; X1 now 011412
[[/code]]

Index register is X1; first time through the loop, X1 gets set to instruction A field; check.

Going into the AWCA

[[code]]
DBG(502162211)> CPU REGDUMPAQI: A=405536000466 Q=233045000000 IR:
[[/code]]

A is 405536000466, carry is not set.

[[code]]
DBG(502162213)> CPU CORE: core_read  60417412 000000000016 (Read)
[[/code]]

Operand is 000000000016

After AWCA

[[code]]
DBG(502162213)> CPU REGDUMPAQI: A=405536000504 Q=233045000000 IR:Neg
[[/code]]

[[code]]
405536000466 + 000000000016 + 0 = 405536000504
[[/code]]

[[code]]
DBG(502162213)> CPU REGDUMPAQI: A=405536000504 Q=233045000000 IR:Neg
[[/code]]

Check.

RPT does its thing:

[[code]]
DBG(502162213)> CPU TRACE: RPT/RPD delta first 0 rf 0 rpt 1 rd 0 e/o 1 X0 054200 a 0 b 0 xN 1
DBG(502162213)> CPU TRACE: RPT/RPD delta; X1 now 011413
DBG(502162213)> CPU TRACE: tally 21
DBG(502162213)> CPU TRACE: not tally runout
DBG(502162213)> CPU TRACE: not terminate
[[/code]]

X1 incremented, tally decremented. Check.

Huh. Is that wrong? C was one, so there shouldn't be a tally?

Actually, AL39 is confusing me...

If C = 1, then C(rpt instruction word)0,17 ->  C(X0); otherwise, C(X0) unchanged prior to execution.

The C bit is bit 10; therefore the C bit is part of the data; why would you wnat to have a state bit in the middle of the data?

Next time through the RPT cycle:

[[code]]
DBG(502162215)> CPU TRACE: 00334:000000|025677 4 011412071011 (AWCA 011412,1) 011412 071(0) 0 0 0 11
DBG(502162215)> CPU TRACE: RPT/RPD first 0 rpt 1 rd 0 e/o 1 X0 052200 a 0 b 0
DBG(502162215)> CPU TRACE: RPT/RPD CA 011412

DBG(502162215)> CPU ADDRMOD: R_MOD: Cr=011413
[[/code]]

X1 got incremented; check.

[[code]]
DBG(502162215)> CPU CORE: core_read  60417413 623144202020 (Read)

Previous operand address was 60417412, now 60417413, check.

Operand value looks odd: 623144202020 BCD "SIM+++" . Could be….

405536000504+623144202020 overflows and faults. QED.

Okay, I read up on the RPT instruction and understand the C=1 case better; the high 8 bits of X0 are the tally. Checking the emulator to see what I wrote…

Looks ok.

math fixup

Wrote Add/Sub 18/26/72 to replace AddSubxx, fixing overflow fault issue.

How to test? UnitTests of course. Haven't run those in a while…. 2014 in fact; quick fix to the tidy script…

TestCSR no longer says "Error Return 2". (Bad)

TestEIS still has the un-reversed operands for SB2D (Bad)

TestEIS is now showing "You should not see this" (Bad)

TestIndirect and TestBugs do not show "T-H-A-T-S all folks (from 0|main) !!! " (Bad)

TestConsole does not show "Hello, world" (Bad)