Is multiply by 1000 done with 1000 additions and divide by 1000 done with 1000 subtractions?

Also, RISC does not have decimal/bcd instructions so computers have another way of doing decimal.

Here is a little thought going back to scientific notation and a little C# evaluation run on a PentiumD.

// this was done with 8.5, 5.25 and 8.5, 5.33 inputs double scale = 8.5 * 5.33; // 44.625 45.305 double scale1 = 8.5 * 5.33 * 1000; // 44625.0 45305.0 int scale2 = 85 * 533; // 44625 45305 int scale3 = scale2 / 1000; // 44 45 int scale4 = scale2 % 1000; // 625 305

It is a matter of formatting yhe output to include the decimal point between the divide and modulo result when done on a PC. FPGA needs hardware to handle input and output formatting.

@Tomii: One interesting point I forgot to mention is that you can use BCD representations to represent anything you want -- so you could use BCD to represent integer, fixed-point, or floating-point values -- now my head hurts :-)

No, I actually meant the wealth of numbers that are on the real axiz of the complex plane (ow, that makes my head hurt). A decimal is a fraction (maybe), if you can just figure out what it is. Now, I'm not trying to say any of those ways you can represent the real numbers is correct, because we're almost always going to lose something somewhere.

Like I keep saying, evaluate your alternatives, and choose the method(s) that best match your needs/requirements. My way most assuredly is not the best way, and your mileage (like my own) may vary.

Still on nine's and ten's complements -- as you noted the way we perform a subtraction in binary is based on the fact that performing the operation (a - b) is the same as performing the operation ((a + (-b)). In binary, the -b is the two's complment of +b, and we can easily generate this by inverting all of the bits in b (to generate the one's complemet) and then adding 1. It's also easy to do thsi in hardware, because we already have an adder, so we just invert all of the bits in b and then we set the carry-in to the adder to 1 (which equates to the "add 1").

The cool thing is that we can do much the same thing with nine's and ten's complements.

For those who want to learn more, you can check out my book How Computers Do Math. Also, you might find the following two columns to be of interest:

A lof if folks find it hard to wrap their brains around ten's complements in th econtex tof BCD arithmetic. I like the following graphic (well, I created it, so I would, wouldn;t I?):

Actually, I wrote some articles about this a few years ago (yes, I know you find thsi difficult to believe :-) Check out the following:

Oooooh, I LOVE this stuff. A lot of folks never think about this. In the case of an 8-bit binary value, for example, we can consider it to represent different things, like:

UUUUUUUU An 8-bit unsigned value (0 to 255 in decimal)

SIIIIIII A sign-magnitude value (-127 to +127; includes -0 and +0)

SIIIIIII A two's complement value (-128 to +127; only one 0)

In the case of the sign-magnitude format, the sign-bit just represents + (0) or - (1). In the case of the two's complement representation, the sign bit represents a quantity: 0 = 0, 1 = -128).

The same thing applies to BCD. If we take an 8-bit field, for example, thsi can be used to represent:

UU An unsigned value from 00 to 99

SU A sign-magnitude value from -9 to +9; includes -0 and +0)

SU A ten's complement value (-50 to +49 in decimal)

@Tom: I would guess that the three most common are probably Binary Coded Decimal (BCD), Floating Point, and Fixed Point.

I guess I would have said: Integer (unsigned and signed), Fixed-point, Floating-point, and BCD. Also, integers may be considered to be a special case of fixed-point (i.e., fixed-point without the fractional part).

Traditionally FPGA designers worked predominantly with integer or fixed-point (with some BCD for hardward acceleration targeted at financial applications / high-performance computing). More recently, they are being used to implement floating-point calculations for things like beam-forming and radar applications -- Altera has some real cool stuff in this regard that helps you map a floating-point pipeline onto their DSP slices and programmable fabric.

@Tom: You said There are plenty of ways to represent "real" numbers in a binary system.

The "real" numbers confused me for a moment because in mathematics a real number is a value that represents a quantity along a continuous line -- including integers, fractions, and irrational numbers such as the square root of two. But I think that when you said "real" numbers you meant "numbers in the real world" .. is that right?

Hi Tom -- you've touched on a topic that's close to my heart. As you mention, there are some numbers that are easy to represent in decimal (like 0.1) that cannot be exactly represented in binary (the equivalent to 0.1 is an ever-recurring pattern of 1s and 0s -- since we don't have infinatly large fields in which to store these numbers, we have to truncate, which leads to errors).

Of course, there are some numbers that are difficult to specify in decimal (base-10) -- take 1/3, for example, which equares to 0.333333r (recurring). This would be easy to specify in certain other bases. Similarly, there are some values that are easy to represent in base-2 that cannot easily be represented in base-10.

You mention one reason for using BCD is when you are accepting input from decimal-based devices or providing output to decimal-based devices. There is another big reason -- in many countries it is mandated by law that any financial calculations performed on a computer must return EXACTLY the same results as if they had been performed with pencil and paper. This is so that everyone knows exactly what will happen with regard to rounding values and so forth. The only way to achieve this is for the calulations to be performed using some sort of base-10 representation, like BCD. Check out some blogs I wrote on this topic a few years back: Binary Coded Decimal (BCD) 101 and BCD coming to an FPGA near you

Making the Grade in Industrial Design Rich Quinnell16 comments As every developer knows, there are the paper specifications for a product design, and then there are the real requirements. The paper specs are dry, bland, and rigidly numeric, making ...

To save this item to your list of favorite EE Times content so you can find it later in your Profile page, click the "Save It" button next to the item.

If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.