From: jweiss@casbah.acns.nwu.edu (Jerry Weiss)
Subject: Re: Help on RT-11 macro language
Followup-To: vmsnet.pdp-11
Keywords: RT-11, macro
Organization: Northwestern University, Evanston Illinois.
Date: Tue, 5 Jan 1993 02:00:12 GMT

In article <93Jan04.223305.29354@acs.ucalgary.ca> morrow@cns.ucalgary.ca (Bill Morrow) writes:
>Hello all you old fellows,
>
>I have been forced to update some of the PDP-11 assembler acquisition
>software running on our old RT-11 system. Of course,
>there are no comments in the source, to save on disk space.
>A week ago, I knew absolutely nothing about PDP-11 macro language.
>I have been wading through the "Orange Wall", but
>I'm a bit confused by the unconditional branch instruction -
>where does this code end up after the 'BR 10$+2' step?
>
>DR3INT: 0
>	BR	10$+2		<--- branch to where ?
>	BR	20$+2
>10$:	MOV	#107,DMACSR
>	TST	ADCO		<--- here ?
>	BEQ	11$
>	MOV	#113,KWREG
>11$:	MOV	DR3INT+4,DR3INT
>	TR			<--- or here ?
>12$:    et cetera ad nauseum
>

This is definitely brain damaged Macro-11 from where I sit, but I won't make
any claims to be a Macro-11 guru.  There's not enough to make a complete
diagnosis, but here is a try.

DR3INT: appears to be a the head of a table with 3 (word) entries.  Entries
two and three appear to references to labels 10$ and 20$ with a 2 byte
adjustment.  The code at 11$, moves the third element into the first
element.  This makes it self modifying code at element 0. Element 0 is
intended to be executed directly, while elements 1 and 2 are the data for
element 0. This is nearly always a bad thing, except in real time interrupt
code, when it is still a bad thing except when it saves the project and
becomes a good thing.  Now if the machine tries to execute at label DR3INT:
it executes a branch instruction (relative to the pc).  The real hack here
is that the branch instructions have an additional two byte offset added.
This is okay for the first entry, because it is effectively moved two bytes
backward to put it in the DR3INT: postion.  This makes it an effective BR
10$.  The second entry is completely strange because it really needs a 4
byte offset (provided it is ever "mov"ed to DR3INT).  Otherwise it will
branch to a location 2 bytes short of 20$.  Since I don't see that section
here, I can't guess what would happen.  Since instructions are either 2,4
or more bytes. It could even miss its intended location and try to execute
some instruction arguments as instructions instead.





>My intuitive guess is that it ends up at 'TST ADCO',
>but the manual seems to be telling me it branches to
>the indicated address.

No.  I know its confusing for a novice, but it probably goes to the 
10$:	MOV	#107,DMACSR
I suspect this is code to enable interupts on the device and tries to
initialize a dma transfer.  Then it tests ADCO for errors (A/D complete?).

>
>While you're here, does the 'MOV' instruction at 11$ really move
>the label 'DR3INT' to the same address as 10$? Why is the 
>'BR 20$+2' there then?
>
Well,  a problem here is that the original contents of DR3INT: are not
initialized, so the flow of the code has to take it to 11$ first or
something else will have to take care of setting up DR3INT:


>What does 'TR' do? I can't find it in the instruction set
>or the macro language reference manual.
>

Got me, perhaps its a defined macro.  Check the macro or source librarys.


If you want more help, you might want to tell us the hardware involved
(dma and A/d Boards).  I would suggest posting followups to vmsnet.pdp-11
if possible.





-- 
Jerry S. Weiss	  "If you can't stand the heat, stay out of the antimatter!"
j-weiss@nwu.edu    Dept. Medicine, Northwestern Univ. Medical School
Newsgroups: comp.os.misc