1

I've coded a number of integer multiplication routines for Atmel's AVR architecture. I found following a simple pattern for the multiplier (and a similar one for the multiplicand) useful, if unconvincing (start at zero, step by a one in every byte (in addition to eventual carries)).
There seems to be quite a bit about testing hardware multiplier implementations, but:
What can be recommended for testing software implementations of integer multiplication? Exhaustive testing gets out of hand - if not at, then beyond 16×16 bit.

greybeard
  • 2,015
  • 5
  • 20
  • 51
  • Hey greybeard, I'm sorry that I can't help, but I am curious as to why you are testing this. Is this an exercise for a regulatory agency, or do you feel a genuine need to test this? Have you experienced a bug before? – Frederick Nov 13 '15 at 14:47
  • Coding this beast of a [case-by-case-multiply](http://stackoverflow.com/a/31074276/3789665), I found the pattern approach to save time over thinking overly hard - and an exhaustive test beyond my patience. – greybeard Nov 13 '15 at 15:14
  • why man. why are you doing this? – Frederick Nov 13 '15 at 16:18

1 Answers1

0

Most approaches uses Genere & Test

  1. generate test operands

    The safest is to use all combinations of operands. But with bignums or small computing power or memory is this not possible or practical. In that case are usually used some test cases which will (most likely) stress the algorithm tested (like propagating carry ... or be near safe limits) and use only them. Another option is to use pseudo random operands and hope for a valid test sample. or combine all these in some way together

  2. compute multiplication

    Just apply the tested algorithm on generated input data.

  3. assess the results

    so you need to compare the algorithm(multiplication) result to something. Mostly use different algorithm of the same process to compare with. Or use inverse functions (like c=a*b; if (a!=c/b) ...). The problem with this is that you can not distinguish between error in compared or compared to algorithm ... unless you use something 100% working or compare to more then just one operation... There is also the possibility to have precomputed result table (computed on different platform 100% bug free) and compare to that.

AVR Tag make this a tough question. So some hints:

  • many MCU's have a lot of Flash memory for program that can be used to store precomputed values to compare to
  • sometimes running in emulator is faster/more comfortable but with the risk of dismissing some HW related issues.
Community
  • 1
  • 1
Spektre
  • 41,942
  • 8
  • 91
  • 312