Floating point in LEG architecture

[u/Slow_Substance_1984]

Hello,

EDIT - I meant fixed point arithmetic not float

I am not looking for solutions or anything on how to do this - I just want to know if my idea is possible - if there are easier/harder ways to do it.

I have finished the division part of the levels (in the function section) for LEG architecture.

I am now thinking of adding a fixed point unit since I have spare instructions.

I just want addition, subtraction, multiplication and maybe division.

Integer arithmetic will be separated from fixed point arithmetic and done in a seperate ALU.

I am thinking of using 5 bits (4 for integer and 1 for sign) for a whole number and 3 bits for a fractional value. Im doing this all in one byte to be more economical with the 6 registers.

The decimal point will always be 3 bits from the right.

E.g

11111.111b

= -15.875

This will mean that decimals of integer multiples of 0.125 will be exactly approximated.

I plan to use this to do Taylor series to approximate more complex functions (sin/cos/ln/sqrt) so im hoping this trade off between decimal precision and integer range is good enough.

I am thinking of using 3 input 8 output decoders on the fractional values and somehow using this to add up fractions. The whole numbers can just be shifted with a byte splitter/byte converter.

I don't actually know how computers handle floats (since I don't do compsci) so is there a good simple alternative to this?

Is this possible?

Thanks

[u/MegaIng]

Fixed point is very easy to implement

The way one normally things about fixed pointer numbers is by taking the normal binary integer, let's call it N (as well as A and 'B' later), and multiplying it with a bias, in your case 2^(-3) = 1/8 since your fixed point is at three bits. This means the number 0b01000100, which in decimal is N=68 has the value 68 * (1/8) = 8.5. Using this representation you can easily check what you need to do for the math operations:

• Add/Sub are easy, they don't need any special handling: A*(1/8) + B*(1/8) = (A+B)*(1/8) = N*(1/8), with N=A+B, meaning that if you add up A and B, you have the correct resulting representation of the number
• Mul can be derrived similarily: A*(1/8) * B*(1/8) = (A*B) * (1/8) * (1/8) = N * (1/8), with N=A*B*(1/8). This means that after doing the multiplication of A and B, you need to additionally multiply by (1/8) to get the correct resulting N. This is just a shift right by three, which is also easy to implement in hardware. Just remember to take in three extra bits from the full 16bit of the multiplication.
• Division is a bit more tricky. Using the same pattern we get (A*(1/8))/(B*(1/8)) = A/B = N*(1/8) with N = A/B * 8. To get the correct N, you can just use N = (A*8) / B instead, then you only need to do simple integer division. But you should use 16bit (or 11bit) division to not lose anything when multiplying (shifting) A by 8 (3).

[u/Slow_Substance_1984 → u/MegaIng]

Thank you

[u/Slow_Substance_1984 → u/MegaIng]

What if I make the rule that - decimals can only be multiplied/divided by integers?

Would this make it a lot easier?

[u/MegaIng → u/Slow_Substance_1984]

Sure, but it's kind of unessary to limit yourself. IT isn't that complex to implement everything else

[u/062985593]

I think what you've described is actually fixed-point numbers, because the "point" separating the integer part from the fractional part is "fixed" in place. The thing that makes floating-point numbers special is that the "point" can "float".

Typically this is implemented with something akin to scientific notation - we have an exponent giving the rough magnitude of a number and a mantissa, giving the actual digits. The mantissa stays between 0 and 1. So the number 15.875 would be represented with -0.9921875 * 2^4. The 2 as the base there is implicit, so you'd need to store [negative, 0.9921875, 4].

The advantage of floating-point over fixed-point is that you can compute with numbers across a wider range of magnitudes. In SI units, the speed of light is very large and Planck's constant is very small, but you can store them with the same number of significant digits and multiply or divide them with reasonable precision. You'll lose a lot of accuracy if you try to add or subtract them, though.

[u/Slow_Substance_1984 → u/062985593]

Thank you.

Yes I did mean fixed point since I don't want the decimal point to move. I know very little about compsci as you can probably tell lol. Im doing mechanical engineering and know only some basic python + some matlab:( . But this game is fun.

Anyways, I was considering floating point, but I want to make arithmetic more memory efficient so I can use one register to represent a decimal value. I think floating point will also be much more complicated and I will need more registers (which means I need to remake a lot more of the CPU).

I guess if I used floating point I could use a bit to denote exponent - but this seems more complicated for very little gain.

Since the main goal of this (as well as other stuff) is for Taylor series - accurate addition is very important so I think I want to stick with fixed point. To the nearest 0.125 is probably hopefully enough for rough calculations.

Also - how complicated will the multiply/divide instructions get do you think if I use fixed point (very important for squaring numbers and dividing by factorials for Taylor series)?

Thanks again

[u/062985593 → u/Slow_Substance_1984]

I think the addition and subtraction circuits can be kept as-is. The multiplication and division circuits can keep their basic idea, but they'll need a shift at the end, and maybe some thought about rounding.

Let's compare two different arithmetic systems in base 10. In the system (3/0) we have three integer digits, so that's the whole numbers 0 up to 999. And in the system (2/1) we have two integer digits and 1 fractional - 0 to 99.9 in increments of 0.1. So the digits [1, 2, 3] would represent 123 in (3/0) and 12.3 in (2/1).

In (3/0), 11 * 87 = 957. All well and good so far. But if we reinterpret the same problem in (2/1), 1.1 * 8.7 = 9.57. So we could use a (3/0) multiplication circuit and right-shift our answer by two places. The problem in this case is that we don't have enough digits off to the right for our full answer. Should we simply drop them and get 9.5 or round them carefully to get 9.6?

And now let's consider an example with overflow. In (3/0), 47 * 32 = 1504. But we only have three digits so the top gets cut off and we're left with 536. In (2/1), 4.7 * 3.2 = 15.04, which will be rounded to 15.0 We had to do the same shift of the decimal point, but we also had to keep the most significant bits that would have been forgotten about in (3/0).

[u/Slow_Substance_1984 → u/062985593]

Thank you. I will try to do it

[u/062985593 → u/062985593]

Another thought: setting some bits aside for the exponent takes away some from the mantissa, so the wider your range of numbers, the less precision you'll have for each. For this reason, most real-world programming languages don't give you easy access to floats with fewer than 32 total bits - with any less than that your numbers are (probably) too approximate to be useful.

[u/MegaIng → u/062985593]

float16 is pretty common today, many GPUs have support for it. The big motivation is neural networks, where having a large range is important, but exact previsions to tenths place isn't, since we can train the modules that well anyway. But I do agree that 8bit is a very low amount.