My assumption is that these instructions are, or at least were, implemented in hardware gates, so these "boundary conditions" are likely to be mechanistic in nature rather then implemented via "if it's a funny number then do this different thing" programming.
We sat down the other day and confirmed, to our own minds at least, that that's the case for LCR. Ian On 27 Apr 2022, 15:08, at 15:08, Martin Ward <mar...@gkc.org.uk> wrote: >On 27/04/2022 01:53, Paul Gilmartin wrote: >> This works correctly (and I'll >> trust the C compliers) only if both LPR and LCR result in 0x80000000, >> or at least some nonzero result. > >If you want to define "LPR" as "make the result a positive number >with the same absolute value as the original", then there is no >defined result for LPR on 0x80000000 because the positive value >has no representation in 32 bit two's complement. > >LPR can more reasonably be defined as "if the value is already >positive, >do nothing, otherwise take the complement". > >LCR is defined as "flip all the bits and add one, ignoring overflow". >With this definition, LCR of 0x80000000 is indeed 0x80000000. > >John von Neumann suggested use of two's complement binary >representation >in his 1945 "First Draft of a Report on the EDVAC proposal for an >electronic stored-program digital computer". > >Mathematically, two's complement can be defined by two rules: > >(1) Arithmetic operations for signed values are the same >as for unsigned values. So -1 is represented as 0xFFFFFFFF >since adding one to this value using unsigned arithmetic >gives the result of 0x00000000 (-1 can be defined as >"the number which gives a result of zero when you add 1 to it"). > >(2) All numbers with the top bit set are negative, >and the rest are positive or zero. >This rule defines the boundary between negative and positive >numbers, and means that 0x80000000 is negative and is the >lowest negative number (since if you subtract one from it, >the top bit flips and you get 0x7FFFFFFF which is therefore >the largest positive number). > >So this explains why both LPR and LCR of 0x80000000 >result in 0x80000000. > >-- > Martin > >Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk >G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
