I'm working my way through Ralph Gorin's "Intorduction to DECSYSTEM-20 Assembly Language Programming". For one of the exercises I wanted to initialize an accumulator to a negative integer value. My first try was an assembly instruction like:

MOVEI 10,-6 ;Move -6 to accumulator 10

However, when the program runs, the contents of the accumulator are not treated like a negative number, and DDT shows the contents of accumulator 10 to be 777772.

Next I tried:

MOVNI 10,6 ;Negate 6 and move result to accumulator 10

Which gets treated like a negative number as expected. DDT shows the contents of the accumulator after the above instruction to be -6 (777777,,777772).

I couldn't find an explanation for this in the Gorin text, but think I have figured out what is going on with the MOVEI instruction:

1. The assembler sees "-6" in the program source and interprets it as a 36-bit (one word) twos-complement integer value, 777777,,777772.
2. Based on where the "-6" appears in the instruction syntax, the value is assigned to the instruction's address field Y.
3. Since the Y field is only 18-bits long, the value's upper half-word is truncated, and the value actually assigned to the Y field is 777772.
4. MOVEI takes the Y value and assigns it to the accumulator.
5. Since the accumulator is a 36-bit word and the value of Y is only 18-bits, the upper half-word of the accumulator is set to 0, making the contents of the accumulator 0,,777772, which is not the same as -6 (777777,,777772).

On the other hand, MOVNI takes positive 6, negates it (777777,,777772), then puts that value in the accumulator like I wanted.

Have I got it figured out, or is something else going on? (I'm working on twenex.org TOPS-20.)

According to David Meyer <papascave@gmail.com>:
> MOVEI 10,-6 ;Move -6 to accumulator 10 doesn't work
>
> MOVNI 10,6 ;Negate 6 and move result to accumulator 10 does work

>5. Since the accumulator is a 36-bit word and the value of Y is only 18-bits, the upper half-word of the accumulator is set to 0, making the contents of the accumulator 0,,777772, which is not the same as -6 (777777,,777772).
>
>On the other hand, MOVNI takes positive 6, negates it (777777,,777772), then puts that value in the accumulator like I wanted.

That is correct. One of the fun things about the PDP-10 is that there are at least three ways to do anything,
so this will also work

HRROI 10,-6

That's half right to right ones immediate, which puts the immediate
777772 in the low half, and sets the high half to ones to make it a
proper negative number.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

This will sign-extend any 18-bit number:

HRREI 10,NUMBER

David Meyer <papascave@gmail.com> writes:

> I'm working my way through Ralph Gorin's "Intorduction to DECSYSTEM-20
> Assembly Language Programming". For one of the exercises I wanted to
> initialize an accumulator to a negative integer value. My first try was an
> assembly instruction like:

> MOVEI 10,-6 ;Move -6 to accumulator 10

> However, when the program runs, the contents of the accumulator are not
> treated like a negative number, and DDT shows the contents of accumulator 10
> to be 777772.

> Next I tried:

> MOVNI 10,6 ;Negate 6 and move result to accumulator 10

> Which gets treated like a negative number as expected. DDT shows the contents
> of the accumulator after the above instruction to be -6 (777777,,777772).

> I couldn't find an explanation for this in the Gorin text, but think I have
> figured out what is going on with the MOVEI instruction:

Ralph's book assumes that the reader/student has access to the PDP-10 Hardware
Reference Manual, which explains this in gory detail.

> 1. The assembler sees "-6" in the program source and interprets it as a
> 36-bit (one word) twos-complement integer value, 777777,,777772.
> 2. Based on where the "-6" appears in the instruction syntax, the value is
> assigned to the instruction's address field Y.
> 3. Since the Y field is only 18-bits long, the value's upper half-word is
> truncated, and the value actually assigned to the Y field is 777772.
> 4. MOVEI takes the Y value and assigns it to the accumulator.
> 5. Since the accumulator is a 36-bit word and the value of Y is only 18-bits,
> the upper half-word of the accumulator is set to 0, making the contents of
> the accumulator 0,,777772, which is not the same as -6 (777777,,777772).

> On the other hand, MOVNI takes positive 6, negates it (777777,,777772), then
> puts that value in the accumulator like I wanted.

> Have I got it figured out, or is something else going on? (I'm working on
> twenex.org TOPS-20.)

Yes, you've figured it out, but using the HRM would have been a lot simpler.

http://bitsavers.org/pdf/dec/pdp10/1982_ProcRefMan.pdf

You should also have access to the Macro reference manual.

http://bitsavers.org/pdf/dec/pdp10/TOPS20/AA-4159C-TM_Macro_Assembler_Reference_Apr78.pdf

Have fun!

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Lars Brinkhoff <lars.spam@nocrew.org> writes:

> This will sign-extend any 18-bit number:

> HRREI 10,NUMBER

As Larry Wall likes to claim about perl, There's More Than One Way To Do It.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

With the later versions of Macro and the tops-20 macros, you could use
MOVEX 10,-6

The MOVEX macro will determine the size of the value, and use the proper instruction
to do it all magically.

fishtoprecords <pat22043@gmail.com> writes:

> With the later versions of Macro and the tops-20 macros, you could use
> MOVEX 10,-6

> The MOVEX macro will determine the size of the value, and use the proper
> instruction to do it all magically.

The macro is actually named MOVX, and in this particular use case generates

HRROI 10,-6

(NB: I just tested this out live on a Toad-2.)

To use the macro, include the line "SEARCH MACSYM" after the TITLE statement in
your program.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

All PDP10 instructions are of the form Operator Accumulator,(indirect)offset(index). MOVEI just moves the effective address computed into accumulator. Since this is computed to 18 bits you get zeros in the upper 18 bits. This is why MOVEI ac,-6 results in AC having 0,,-6 rather than -1,,-6 as you would expect. HRREI ac,-6 is probably the fastest. MOVNI has the extra step of negating the value of ea.

Rich

"kgxxx10@yahoo.com" <kgxxx10@yahoo.com> writes:

> All PDP10 instructions are of the form Operator Accumulator,(indirect)offset(index).
> MOVEI just moves the effective address computed into accumulator. Since this
> is computed to 18 bits you get zeros in the upper 18 bits. This is why MOVEI
> ac,-6 results in AC having 0,,-6 rather than -1,,-6 as you would expect.
> HRREI ac,-6 is probably the fastest. MOVNI has the extra step of negating
> the value of ea.

Actually, HRROI is faster than HRREI because it simply sets the left half to -1
(all 1 bits), while "extend the sign" requires the testing of the sign bit of
the right halfword before setting the left half appropriately.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On Wednesday, January 26, 2022 at 5:09:42 PM UTC-5, Rich Alderson wrote:
> fishtoprecords <pat2...@gmail.com> writes:
>
> > With the later versions of Macro and the tops-20 macros, you could use
> > MOVEX 10,-6
>
> > The MOVEX macro will determine the size of the value, and use the proper
> > instruction to do it all magically.
> The macro is actually named MOVX, and in this particular use case generates

Thanks, I was going from memory that is a few decades old.

On Thursday, January 27, 2022 at 7:01:59 PM UTC-5, Rich Alderson wrote:
> Actually, HRROI is faster than HRREI because it simply sets the left half to -1
> (all 1 bits), while "extend the sign" requires the testing of the sign bit of
> the right halfword before setting the left half appropriately.

There were two cool things that using the MOVX macro gave you:
1) it would automatically pick the fastest equivalent instruction
2) it would do the right thing based on the value, which can require thinking if you are turning on a bunch of flags
or other constants that are not readily at hand.

On Thursday, January 27, 2022 at 4:01:59 PM UTC-8, Rich Alderson wrote:

(snip)

> Actually, HRROI is faster than HRREI because it simply sets the left half to -1
> (all 1 bits), while "extend the sign" requires the testing of the sign bit of
> the right halfword before setting the left half appropriately.

For most processors, it is hard to make statements about the speed of
instructions based on the work done. In many cases, the designers optimized
one path as being more common, even if it looks like it should take longer.

In the case of PDP-10 instructions, I suspect you need to specify the model.
(Actually that is true for pretty much all processors, but maybe a little more
for the PDP-10.)

The KA-10 has a lot of asynchronous logic, so might be able to do some
things just a little faster. Others will need whole clock cycles. For the KA-10,
it might be slightly different for different values.

In the PDP-10 days, it was usual for manufacturers to give instruction
timing information. With pipelined processors, and various other changes,
it became much more difficult to do instruction timing, so the only way
is with reliable benchmark programs.

On Thursday, January 27, 2022 at 7:52:20 PM UTC-5, gah4 wrote:
> On Thursday, January 27, 2022 at 4:01:59 PM UTC-8, Rich Alderson wrote:
>
> (snip)
> > Actually, HRROI is faster than HRREI because it simply sets the left half to -1
> > (all 1 bits), while "extend the sign" requires the testing of the sign bit of
> > the right halfword before setting the left half appropriately.
> For most processors, it is hard to make statements about the speed of
> instructions based on the work done. In many cases, the designers optimized
> one path as being more common, even if it looks like it should take longer.

Depending on model. On KA10, and KI10, they execute in same time. I suspect also on KL10. There is no test for the sign, the bit is just copied.

Rich

On Friday, January 28, 2022 at 3:07:44 PM UTC-8, kgx...@yahoo.com wrote:

(snip, I wrote)

> > For most processors, it is hard to make statements about the speed of
> > instructions based on the work done. In many cases, the designers optimized
> > one path as being more common, even if it looks like it should take longer.

> Depending on model. On KA10, and KI10, they execute in same time.
> I suspect also on KL10. There is no test for the sign, the bit is just copied.

Yes, after I wrote that I looked up the manual. It is pretty easy to see for the KI
that all H...I instructions are the same time. It is a little harder to figure out
for the KA, but I believe so. I suspect also for the KL, as it is usually
more true on faster processors.

That leaves the KS, which I don't know about.