How to correctly reset the NEG flag in a LMC without storing said variable then loading it again?

Question

My given task is to find the mean of the sum of 3 inputs rounded down using LMC. To which I had the following code:

    LDA zro
    STO r
    STO cnt
    LDA t
    STO abc
lp  IN  
    STO a 
div LDA a
    SUB t
    ADD r   
    BRP x
    BRZ x
    BR  y
x   STO a    
    LDA cnt
    ADD one
    STO cnt   
    LDA zro
    STO r
    BR  div
y   ADD t
    STO r 
    LDA abc
    SUB one
    STO abc
    BRZ out
    BR  lp
out LDA cnt
    OUT
    HLT
a   DAT 000
t   DAT 003
cnt DAT 000
one DAT 001
abc DAT 003
r   DAT 000
zro DAT 000

which works for 99% of inputs 0-999, save for a few like:

• 4 4 2

  Produces 2 instead of 3

• 596 165 2

  Produces 253 instead of 254

• 148 574 2

  Produces 240 instead of 241

For these inputs, the program produces a value one less than expected. This is because of a bug where the NEG flag doesn't reset until a new value is loaded.

For example with 4,4,2 during the last input loop where 2 is input (abc=1), we have a=2; 2 - 3 = (999 NEG) + 2 = (1 NEG) which should've been just 1. But the NEG flag hasn't been reset leading the branching into the wrong line (y instead of x). Therefore cnt is one less than expected.

My question then is how do you fix that (with minimal added instructions)?

Answer 1

Indeed, with LMC it is not good to perform an ADD immediately after a SUB because of the effect on the negative flag and on the accumulator. Not only could ADD clear the flag or not (depending on the simulator), the accumulator value after a SUB is not defined either, although most LMC simulators will use modular arithmetic (or will allow the accumulator to really have a negative value), this behaviour cannot be relied on.

The solution is to first check with BRP whether the SUB didn't overflow below zero, and then -- if it did -- load the accumulator again with the original value before the subtraction was done. It is the most reliable way to proceed (in terms of portability of the code).

Some other comments:

• BRZ has little sense when it follows immediately after a BRP as the latter will branch also when the accumulator's value is zero.

• The name out for a label is ambiguous: some LMC simulators might interpret it as the instruction OUT and will not be able to parse the program.

• The names r, t, x, y, cnt, ...etc are not very descriptive. I wouldn't abbreviate anything and just use longer labels: it will improve the readability of the code.

• I would not add the remainder repeatedly to the current value during the division process (in x), as in most cases the remainder will be 0. You could do this in the case where the last subtraction was performed (the y case), and only then reset it to zero, and perform one more iteration of the division loop (as now the current value might be between 3 and 5).

• If you swap the blocks for x and y you can save one BR instruction.

So here is the modified code -- you can run it here:

#input: 4 4 2
           LDA zero
           STO remainder
           STO average
           LDA three
           STO inputcount
getnext    IN
           STO value
divide     LDA value
           SUB three
           BRP positive
           LDA remainder # ignore the subtraction of 3
           BRZ continue  # branch if no remainder
           ADD value # now we have no problem with NEG flag
           STO value # remainder is added
           LDA zero
           STO remainder
           BR  divide # repeat one more time
positive   STO value
           LDA average
           ADD one
           STO average
           BR  divide
continue   LDA value
           STO remainder
           LDA inputcount
           SUB one
           STO inputcount
           BRZ output
           BR  getnext
output     LDA average
           OUT
           HLT
value      DAT 0
average    DAT 0
inputcount DAT 3
remainder  DAT 0
zero       DAT 0
one        DAT 1
three      DAT 3



<script src="https://cdn.jsdelivr.net/gh/trincot/[email protected]/lmc.js"></script>