Hi,

That sounds reasonable.

If you have 7 bits that is 0 to 127, 128 possibilities only 100 are used, the 8th bit adds 128 possibilities that are unused, so that's 128+28=156 unused combinations.

While you CAN encode both inputs into a 7-bit pattern, that is PROBABLY (in fact, almost certainly) not what was intended as both inputs are independent 4-bit entities. The output can be restricted to a 7-bit pattern easily (and reasonably) since it is a single entity that just needs 82 possible values. If we were to be really strict, the output actually only needs six bits because, if I've counted right, there are only 37 possible distinct outputs from the product of two single digit numbers. But encoding them this way would almost certainly be considered an unreasonable solution.

 

While you CAN encode both inputs into a 7-bit pattern, that is PROBABLY (in fact, almost certainly) not what was intended as both inputs are independent 4-bit entities. The output can be restricted to a 7-bit pattern easily (and reasonably) since it is a single entity that just needs 82 possible values. If we were to be really strict, the output actually only needs six bits because, if I've counted right, there are only 37 possible distinct outputs from the product of two single digit numbers. But encoding them this way would almost certainly be considered an unreasonable solution.

Hi there,

Yes, and the 7 bits i was referring to was the output 7 bits. I would think encoding would be too extreme too.

Back when computers were still fairly new like 1980's i had to do a lot in ASM. I made a BCD multiplication routine in a manner similar to this. Just a lookup table. The two inputs were the two current digits to be multiplied. It was part of a bigger routine that multiplied two large integers and also kept track of the exponent. I had it set up to handle a lot of digits, and of course part of that routine was the adder that added numbers with lots of digits. That was probably 10 years before numerical processors came out like (if i rem right) the 80387 number processor.