Floating point arithmetic

[cadet1620]

[Update 23 Sept 2012, Float_1_1.zip -- code fix.]
[Update 27 Sept 2012, Float_1_2.zip -- require explicit Float.init() call.]
[Update 1 Nov 2012, finally got my VM translator optimization good enough so the asm fits in ROM.]
[Update 1 June 2013, Float_1_3.zip -- bug fix: x.mult(x) failed if x<0.]
[Update 12 Oct 2014, Float_1_4.zip -- bug fix: missing ()s precedence problem in test code.]
[Update 13 Oct 2014, Float_1_5.zip -- cleanup: all expressions fully ()ed for explicit precedence.]

Here's the result of my latest hacking on Hack:

I wrote a Float class that supports floats with 32-bit mantissas with 10-bit exponents, giving 9-1/3 decimal digit precision with 10^±154 range.

It runs on the VM emulator and the CPU emulator (without the call to the test suite). Here's the code if you want to play with it. Binary: Float.hack Source: Float_1_5.zip

The phi computation looks like this:

    function void phi()
    {
        var Float f;
        let f = Float.new();
        do f.setInt(5);
        do f.sqrt();
        do f.addInt(1);
        do f.divInt(2);
        do Output.printString("phi = ");
        do f.print(10);         // 10 sig. fig.
        do Output.println();
        do f.dispose();
        return;
    }

eⁿ values were calculated using Taylor series.

Like most late night projects, it could use better comments...

--Mark

[Dano]

Nice job!

[Dano]

Cadet, enjoy running your program on CPU emulator as well! I managed to compile it, but i had to exclude FloatTest.jack

float.hack

[cadet1620]

Dano wrote

Cadet, enjoy running your program on CPU emulator as well! I managed to compile it, but i had to exclude FloatTest.jack

This was built from the 1.1 sources which have an initialization problem.  Please be sure to use the CPU Emulator's "Clear RAM" button before running, or it may crash.

The main post now has the 1.2 sources.

--Mark

[JavaJack]

Nifty. I always wondered if it would it be tough to add shift left and shift right opcodes to the CPU, in order to do 8.8 fixed point math.

[cadet1620]

JavaJack wrote

Nifty. I always wondered if it would it be tough to add shift left and shift right opcodes to the CPU, in order to do 8.8 fixed point math.

Hack specifies that bits 13 and 14 in c-instructions are 1 so it's not hard to add 3 more instruction groups.  One of them could be a shift instruction using the 6 ALU bits to encode direction, shift/rotate, 0-15.  I see Mux16Ways in your future...

If you also want to be able to do multi-precision arithmetic efficiently, you'll want to add an ALU carry out latch and add/sub with carry instructions.

Lots of opportunity to play.  Let us know what happens.

--Mark

[JavaJack]

I'm kind of getting the gist of how it would work by studying the barrel shifter applet here:
http://tams-www.informatik.uni-hamburg.de/applets/hades/webdemos/10-gates/60-barrel/shifter8.html

Assuming I haven't misinterpreted it, it looks like you'd just need a network of 64 2-in/1-sel/1-out muxes for left shift, and another network of 64 for right shift. Then a 16-in/1-sel/16-out to choose between left or right.

Modifying the TECS CPUEmulator application is a whole other problem, though.

[JavaJack]

Turned out to be easy, thanks to that applet as a visual guide, without which I probably would have been screwed. I just wrote a functional ShiftLeft16.hdl, ShiftRight16.hdl and BarrelShifter16.hdl that work in the TECS Hardware Simulator.

[tungsten]

Hi Mark

How would you rewrite the following functions if you had access to hardware logical bit shifting ('<<' and '>>' operators)?

- int   _mant_SHL1 () {}
- void _mant_SHR1 () {}
- void _mant_SHR   ( int n ) {}
- int   _mant_SRA   ( int n ) {}
- void _mant_ROL   ( int n ) {}

For example the variables msw and lsw are used in the above functions. What do they represent? Are they needed if you have access to hardware logical bit shifting?

Thanks for your time!

[cadet1620]

The mantissa is a 32-bit quantity.  "msw" is the most significant 16-bit word and "lsw" is the least significant 16-bit word.  Their function would be unchanged if hardware shifting was available.

To take advantage of hardware shift instructions in this code, the first things one would need to do would be to add shifting operators like "<<" and ">>" to the Jack namguage and their equivalent commands to the VM translator.  These operators whould be similar to C's shifts.  "x << n" would translate to VM "push x; push n; shl"  The VM translator would be responsible for using the new hardware instructions.

--Mark

[tungsten]

Thanks for the reply.

I have already added the operators to the compilers and such. I wanted to optimize the floating point code (for speed) to take advantage of this.

[tungsten]

However, knowing the variable meanings is helpful for understanding the code. I'll give it another go.