19 Aug
2006
19 Aug
'06
9:37 a.m.
On Aug 19 2006, 9:38, Wolfe, Julian wrote:
I got the 11/34 up and running, and I loaded XXDP. It
fails the trap
test. The instructions state you should examine the stack pointer
(777706) which shows it to be a value of 000470. This is supposed to
tell you the address of the Program Counter, right? So I load address
470, and the value is 000330. What instruction is failing? Am I
reading this right?
Yes, the stack pointer points to the last address used on the stack,
and that will be the value of the PC when it called the error
subroutine, or to put it another way, the address of the next
instruction to be executed had the JSR not been taken. It's failing at
whatever test was just before location 330 -- which is surprisingly
low. You'd need to look at the listing to see what the test was.
--
Pete Peter Turnbull
Network Manager
University of York
19 Aug
19 Aug
11:09 p.m.
Pete Turnbull wrote:
On Aug 19 2006, 9:38, Wolfe, Julian wrote:
The trap test typically does a halt-on-failure, so at what address does
your CPU halt? After knowing the halt address (and the failed test) the
SP and what is on the stack may or may not be useful data.
BTW the listing of this diagnostic is online at:
http://www.bitsavers.org/pdf/dec/pdp11/xxdp/listings/AC-8045D-MC_CFKABD0-11…
in case you already didn't know this.
If indeed the CPU did halt at 330 this is in the vector space which is
typically populated with .+2/halt word pairs (a 'trapcatcher' in DEC terms).
Don North
I got the 11/34 up and running, and I loaded
XXDP. It fails the trap
test. The instructions state you should examine the stack pointer
(777706) which shows it to be a value of 000470. This is supposed to
tell you the address of the Program Counter, right? So I load address
470, and the value is 000330. What instruction is failing? Am I
reading this right?
Yes, the stack pointer points to the last address used on the stack,
and that will be the value of the PC when it called the error
subroutine, or to put it another way, the address of the next
instruction to be executed had the JSR not been taken. It's failing at
whatever test was just before location 330 -- which is surprisingly
low. You'd need to look at the listing to see what the test was.
19 Sep
19 Sep
6:46 p.m.
Okay, I had a look at the instruction listing and to be honest, have no idea
what I'm looking at. How do I figure out what test was running when it
failed, and how do I decipher what that means? Is 330 the number on the
very left of the page?
If so, it says to scope the problem, replace halt with 240 (is this JMP?)
and replace the next instruction with 703 (what's that? Where I'm jumping
to?)
Anyway, of course, any help would be much appreciated.
Thanks!
Julian
-----Original Message-----
From: cctalk-bounces at classiccmp.org
[mailto:cctalk-bounces at classiccmp.org] On Behalf Of Don North
Sent: Sunday, August 20, 2006 1:10 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: 11/34 failing trap test
Pete Turnbull wrote:
the stack,
On Aug 19 2006, 9:38, Wolfe, Julian wrote:
> I got the 11/34 up and running, and I loaded XXDP. It
fails the trap
> test. The instructions state you should
examine the stack pointer
> (777706) which shows it to be a value of 000470. This is
supposed to
> tell you the address of the Program Counter,
right? So I
load address
470, and
the value is 000330. What instruction is failing? Am I
reading this right?
Yes, the stack pointer points to the last address used on and that will be the value of the PC when it
called the error
subroutine, or to put it another way, the address of the next
instruction to be executed had the JSR not been taken. It's
failing at
whatever test was just before location 330 --
which is surprisingly
low. You'd need to look at the listing to see what the test was.
The trap test typically does a halt-on-failure, so at what
address does your CPU halt? After knowing the halt address
(and the failed test) the SP and what is on the stack may or
may not be useful data.
BTW the listing of this diagnostic is online at:
http://www.bitsavers.org/pdf/dec/pdp11/xxdp/listings/AC-8045D-
MC_CFKABD0-1134-Traps-Tst_Apr77.pdf
in case you already didn't know this.
If indeed the CPU did halt at 330 this is in the vector space
which is typically populated with .+2/halt word pairs (a
'trapcatcher' in DEC terms).
Don North
11:39 p.m.
Julian Wolfe wrote:
Okay, I had a look at the instruction listing and to
be honest, have no idea
what I'm looking at. How do I figure out what test was running when it
failed, and how do I decipher what that means? Is 330 the number on the
very left of the page?
If so, it says to scope the problem, replace halt with 240 (is this JMP?)
and replace the next instruction with 703 (what's that? Where I'm jumping
to?)
Anyway, of course, any help would be much appreciated.
Thanks!
Julian
You need to run the trap test and when it halts (meaning a failure) then
observe the halt address in the lights on the console display. Forget
about the stack pointer and all that stuff until you know where in the
diagnostic the failure is located.
THEN if it is relevant you can examine the registers and/or memory to
get more info. But you need to know what to look for first, and the
starting point is the halt address in the console lights.
Don
21 Sep
21 Sep
11:14 p.m.
Okay, it halts with 20 in the octal display. Is that the address?
I guess I need to take this one step at a time.
On Sep 20, 2006, at 1:39 AM, Don North wrote:
Julian Wolfe wrote:
Okay, I had a look at the instruction listing and
to be honest,
have no idea
what I'm looking at. How do I figure out what test was running
when it
failed, and how do I decipher what that means? Is 330 the number
on the
very left of the page?
If so, it says to scope the problem, replace halt with 240 (is
this JMP?)
and replace the next instruction with 703 (what's that? Where I'm
jumping
to?)
Anyway, of course, any help would be much appreciated.
Thanks!
Julian
You need to run the trap test and when it halts (meaning a failure)
then
observe the halt address in the lights on the console display. Forget
about the stack pointer and all that stuff until you know where in the
diagnostic the failure is located.
THEN if it is relevant you can examine the registers and/or memory to
get more info. But you need to know what to look for first, and the
starting point is the halt address in the console lights.
Don
22 Sep
22 Sep
10:16 a.m.
Julian Wolfe wrote:
Okay, it halts with 20 in the octal display. Is that
the address?
I guess I need to take this one step at a time.
On Sep 20, 2006, at 1:39 AM, Don North wrote:
Ok, this means that the halt instruction was at 16(8) and probably
came from the trapcatcher setup at 14(8). You can verify this by
examining location 14(8) and see that is has a 16(8) in it.
14(8) is the vector for the BPT instruction. Now you need to examine
the SP and look on the stack at (SP) to find the saved PC of where
the actual trap occurred. This should be back somewhere in the program
code (if you are lucky). It could be you are unlucky :-(, your CPU went
wild and just happened to run across an instruction word with an
opcode of 000003 (which is BPT).
23 Sep
23 Sep
2:03 a.m.
On Sep 22, 2006, at 12:16 PM, Don North wrote:
Julian Wolfe wrote:
I did that and got exactly as expected.
Okay, it halts with 20 in the octal display. Is
that the address?
I guess I need to take this one step at a time.
On Sep 20, 2006, at 1:39 AM, Don North wrote:
Ok, this means that the halt instruction was at 16(8) and probably
came from the trapcatcher setup at 14(8). You can verify this by
examining location 14(8) and see that is has a 16(8) in it.
14(8) is the vector for the BPT instruction. Now you need to examine
the SP and look on the stack at (SP) to find the saved PC of where
the actual trap occurred. This should be back somewhere in the program
code (if you are lucky). It could be you are unlucky :-(, your CPU
went
wild and just happened to run across an instruction word with an
opcode of 000003 (which is BPT).
Examining the SP gives me a value of 470(8) on the display. Now, from
what I understand, I should be looking for this address in the
listing, correct?
Here is where I have difficulty; it seems to jump from 342(8) to 500
(8) in the instruction listing. Did my CPU go nuts, or am I just
interpreting this wrong?
I am referring to the gap between lines 107 and 112 on page 5 of the
bitsavers copy of the instruction listing.
Thanks again for your help.
9:37 a.m.
On Saturday 23 September 2006 05:03, Julian Wolfe wrote:
On Sep 22, 2006, at 12:16 PM, Don North wrote:
No, SP (which I take it has the value of 470(8)) is the stack pointer, so you
should look at the contents of address 470(8) to find out the value of PC
when the machine trapped. The notation (SP) means the contents of the
address indicated by SP.
Now, most machines I've used decrement SP *after* storing the value -- which
would mean that the PC should actually be stored at 472(8). Is the PDP-11
different, or should Julian actually be looking at 472(8) instead of 470(8)?
Pat
--
Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
Julian Wolfe wrote:
I did that and got exactly as expected.
Okay, it halts with 20 in the octal display. Is
that the address?
I guess I need to take this one step at a time.
On Sep 20, 2006, at 1:39 AM, Don North wrote:
Ok, this means that the halt instruction was at 16(8) and probably
came from the trapcatcher setup at 14(8). You can verify this by
examining location 14(8) and see that is has a 16(8) in it. 14(8) is the vector for the BPT instruction. Now
you need to examine
the SP and look on the stack at (SP) to find the saved PC of where
the actual trap occurred. This should be back somewhere in the program
code (if you are lucky). It could be you are unlucky :-(, your CPU
went
wild and just happened to run across an instruction word with an
opcode of 000003 (which is BPT).
Examining the SP gives me a value of 470(8) on the display. Now, from
what I understand, I should be looking for this address in the
listing, correct?
11:20 a.m.
Patrick Finnegan wrote:
On Saturday 23 September 2006 05:03, Julian Wolfe
wrote:
That's correct ... you need to look at the memory
location pointed to by the
SP (written as (SP) or @SP to show indirection, as one would write
assembly code).
On Sep 22, 2006, at 12:16 PM, Don North wrote:
No, SP (which I take it has the value of 470(8)) is the stack pointer, so you
should look at the contents of address 470(8) to find out the value of PC
when the machine trapped. The notation (SP) means the contents of the
address indicated by SP. Julian Wolfe wrote:
Examining the SP gives
me a value of 470(8) on the display. Now, from
what I understand, I should be looking for this address in the
listing, correct?
Now, most machines I've used decrement SP *after* storing the value -- which
would mean that the PC should actually be stored at 472(8). Is the PDP-11
different, or should Julian actually be looking at 472(8) instead of 470(8)?
In the
PDP-11 the stack pointer addresses the last word pushed, so in
the case
of a trap, @SP or (SP) will point directly to the word containing the
pushed PC.
So look in memory location 470(8) to see where the code was interrupted.
470(8)
is a reasonable SP for most diagnostics (typically the SP would be setup
to 500
or 1000(8) on startup and build down from there).
20 Sep
20 Sep
4:20 a.m.
"Julian Wolfe" wrote:
If so, it says to scope the problem, replace halt with 240 (is this JMP?)
and replace the next instruction with 703 (what's that? Where I'm jumping
to?)
240 is a nop. I think the branch goes backward but I can't say where (-76?)
[brad at mwave host]$ echo -e -n "\240\0\303\1" >x
[brad at mwave host]$ od -o x
0000000 000240 000703
0000004
[brad at mwave host]$ /opt/tools/dec/pdp11/bin/pdp11-dec-bsd-objdump -D -b binary -m pdp11
x
x: file format binary
Disassembly of section .data:
00000000 <.data>:
0: 00a0 nop
2: 01c3 br 0xffffff8a
-brad
6435
days inactive
6470
days old
9 comments
5 participants
participants (5)
-
ak6dn＠mindspring.com -
brad＠heeltoe.com -
fireflyst＠earthlink.net -
pat＠computer-refuge.org -
pete＠dunnington.plus.com