[HECnet] How long has your 20 been up?

[Johnny Billquist]

On 2022-01-21 01:33, Paul Koning wrote:
> 
> 
>> On Jan 20, 2022, at 5:03 PM, Johnny Billquist <bqt at softjar.se> wrote:
>>
>> On 2022-01-20 22:42, Thomas DeBellis wrote:
>> ...
>>> The carry on the PDP-11 is another thing I forgot about.  The Microsoft C library of the late 1980's handled 32 bit numbers as having the low order 16 bits in the accumulator (AX) and the high order in the data register (DX). ADD AX,/foo/ and ADC DX, 0 was an extremely common sequence and unremarkable sequence in 8086/80286 code.
>>
>> That sequence is simple on a PDP-11, but that just adds a 16-bit number to the 32-bit result. It becomes trickier on a PDP-11 when you want to add two 32-bit values, as the ADC on the PDP-11 *only* adds the carry. That means you get two additions hitting the high 16 bits, which in turn means you are not getting a simple result for the condition codes out of the whole thing. Which makes it even uglier when you want to go for even more than 32 bits...
> 
> Not really, actually.  I went through this in detail when I rewrote the condition code handling in the PDP11 back end for GCC.  You work least to most significant, and the final condition codes are the correct ones except for Z, which of course requires checking the entire multi-word value.  But, say, a statement like "if (x + y < 0)" where x and y are int64 works just fine with no additional work, you just add up the two values (yes, that takes a bunch of instructions) and do a bmi or bpl when done.

It really is a pain. Sure, if you just care about N and Z, you're 
(sortof) good (you have N and can pretty easily check Z). If you want to 
talk about unsigned, or more proper signed, you are not.
Both C and V are broken.

> The fact that PDP11 doesn't have VAX-style add with carry is a nuisance because it means you need two instructions rather than one, and it's annoying because addc is hardware-wise a trivial variation of add.  But given the lack of opcode space for two-operand instructions it makes sense.

No. It's more than that. You need two, if we just talk about a 32 bit 
value. If you go for 64 bits, you end up with 6 extra instructions (in 
addition to the 4 adds), and as mentioned, your flags are all messed up.
And it just grows worse the more bits you want to add.
Now, RSX do deal with quadwords in some places...

>>> What surprised me was that INC (add one) didn't set carry, so you couldn't do an INC AX - ADC DX, 0 sequence which would have been faster.  I never did figure out how that was great.
>>
>> Same on the PDP-11. INC and DEC does not affect the carry. Seems a very conscious choice. Not sure I agree with it, but that's the way it is.
> 
> I'm not sure why that is, either, though it is a very helpful property when coding compact subroutines that indicate success/fail or similar one-bit status through the C bit.  The more confusing one is NEG, which sets C except if the value is zero.  That turns out to be what you need for multi-word negate: it becomes NEG ADC ...

NEG seems totally reasonable.

INC/DEC is different. Yes, sure, in the case you do want to preserve 
carry (a common indicator from routines for success/fail for example), 
it can potentially be useful, but I've seldom ever had an INC/DEC in the 
path which made a difference.
The fact that MOV don't change the carry on the other hand is extremely 
valuable.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol