Actual fix for when `uname -i` doesn't work

Just use `uname -m`

Reflect fixes to I/O in ipdf/vfpu

Commits in ipdf/vfpu:
 354bf006d86abdfad9dbb915facec36f99af77bc
 e005897cffaf46cbbed14b3cc1ef74a390c93fef

Only using 1 hex character for opcode (3 bits) and rmode (2 bits) as opposed to 1 char per bit (...)
Also no need to print extra newline; it was a bug in ipdf/vfpu

Remove REAL_HALF as it doesn't actually implement a half precision float

More to it than just masking bits because the sizes of the exponent differ.
Could just mask bits in the mantissa but I have horrible plans involving VFPU...

Allow VFPU to save output vcd file

That was amazingly simple.
Can run `gtkwave` on the output vcd file to see all the signals!

Modify symlinks

Using a symlink to a symlink... I don't know why. Because I can.

Add rounding mode to VFPU

For some reason it needs an extra newline?
It would be much better if this used binary read/write.

Will look into getting that to happen in the ipdf/vfpu repo at some point.

VFPU now using std::bitset instead of just float typedef

It's still 32 bits. However it might not break if I change it?
Can't test it at the moment because the virtual FPU is 32 bits still.

An interface for a FPU compiled from VHDL

I have tested with the FPU from https://github.com/jop-devel/jop

The way this works is really awful...

1. Make (or steal from jop) a VHDL FPU
2. Make (or steal from jop) a testbench that uses stdio to read operands and ops
   - The jop one reads from a generated file, but it is trivial to change to "STD_INPUT" and remove all the assertion tests.
3. Compile testbench into an executable with ghdl
4. Call VFPU::Start which does the following:
   - Create a socketpair(2)
   - fork(2) and in the child dup(2) stdin/stdout to the socketpair
     - Redirect stderr to /dev/null because the testbench generates 10^3 warning messages
   - in the child, exec(3) the testbench FPU
5. Call VFPU::Exec passing the desired operands and opcodes
   - The operands and opcodes are written as hex strings over the socketpair
   - The child executing the FPU program does its thing
   - The result is read back as a hex string
6. When finished, call VFPU::Halt to kill(2) the FPU

I tried to get ghdl and gcc/g++ to make a static library to call ghdl_main instead
of exec'ing things. But that didn't work. The fork and socketpair would have still been
required for that approach anyway.

TODO:
  - Make the interface (not the FPU) deal with arbitrary size registers
  - Wrap a Real type around it so we can #define REAL_SIMULATED_FPU

I haven't put any of the VHDL in the git repo for obvious reasons.
If I actually start messing with it, it will probably get a seperate repo.

This may end up being a complete waste of time?
Although potentially being able to run an arbitrary FPU albeit in a horrible manner does seem cool.

Fix RealToFloat test (hopefully)

Use x86_64 when uname is broken

Wierd...

>> sam@daedalus:~$ uname -i
>> unknown
>> sam@daedalus:~$ uname -a
>> Linux daedalus 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux

Zoom in and out with the mouse wheel.

Note that zoom-out is totally broken with half-precision,
so single-precision is the default. You can still see some artefacts
in single precision mode if you zoom in enough.

Zoom into the corner of a rectangle and then click on the corner an try to drag it.
Eventually you'll notice the reduced precision, and the rectangle will jump around.

You can move around a document with Click+Drag!

Uses some scary C++11 features, so no idea if this will break the CS Lab machines
and their ancient version of gcc.

It works on the lab machines now, I swear.

Magic SDL2 sauce! Now with 32-bit!

(My deepest and most sincere apologies to anyone who tries to read the Makefile now)

David's secret SDL2 magic sauce!

Add tester for numerical calculation of PI

Calculate PI using float, double and Real and compare the error and performance.

Traditional floats have a point (hardware dependent) where the error starts to behave unpredictably
rather than decreasing with number of intervals - due to rounding/precision errors.
Can see that doubles are better than single precision floats but they still do it.

An infinite precision Real would not have these problems (hah!)
We can at least aim to do better than double.

Based on PHYS CQM/pprog courses from 2012.
Should probably find a literature reference for this.

Save/Load chunks.

Tester to compare custom Real to IEEE float

Also got the endianness right this time. I think.

Make real.h so we can change reals

Needed to fix view.cpp to call Float where it expects GLfloat
Had an attempt at making a half precision float, but it didn't go very well.

I don't think half precision floats are *that* terrible...
Probably got the bit masking wrong.

Merge branch 'master' of git.ucc.asn.au:/ipdf/code

Conflicts:
src/main.cpp

Fixed that and also fixed other things.

Tweak Makefile to make testing nicer

Who said you needed fancy high level languages to do unit testing?

It can't just be done using Make though; a bash script was also needed.

Crazy std::vector<T> loader and saver.

CMake support. We don't have to use it, but it's there if we do.

It now is all the working.

Merge branch 'master' of git.ucc.asn.au:ipdf/code

Add ObjectType for Object Type

Initial outline rendering.

Implement document saving and loading

Also implemented a tester to test it doesn't explode.

We should set this up to make replacing main() easy.

All of the SDL2 graphics stuff.

(With deprecated, obsolete OpenGL functions! Woo!)

Fix makefile.

Added Document and View classes

And member functions for doing stuff.

Document Format completed (not really).

ipdf.h and Real type

Real == float for now. Can make a class and overload it later.

Naming convention:

void ThisIsAFunction(Type this_is_a_var);

Some makefile changes

Add basic code

Log functions & Makefil

The code repository exists....?