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:
div LDA a
x STO a
y ADD t
out LDA cnt
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
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
cnt is one less than expected.
My question then is how do you fix that (with minimal added instructions)?
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.
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.
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
y you can save one
So here is the modified code -- you can run it here:
#input: 4 4 2
divide LDA value
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
BR divide # repeat one more time
positive STO value
continue LDA value
output LDA average
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>