Also changed cycle, instret and time to be directly updated as 64 bits.

The remaining instructions which might need modifications are:
  Floating point (which shouldn't need to change)
  JALR
  Immediate mode shifts
  Stores and loads need a little update to support new instructions

Also this fixes a bug in backstepping FSD and a tautologically true test.

On change of this setting all instructions are reloaded and ones that
don't work in the current mode will fail to initialize. Its a kindof
hacky solution, but it does allow overwriting other instructions.

The mechanism for failing to load is BasicInstruction throwing a null
pointer exception.

This was quite difficult to actually implement, but is quite
neccessary to automatically run tests from riscv-tests. Most
of the difficulty stemmed from a bunch of places in the code
expecting the biggest value would be an int rather than a
long.

However, making li work with 64 bit values was also a little
bit of work. It neccessitated making 5 new types of Psuedo-op
templates.

.dword was relatively simple after li wsa working, but required
modifying a significant amount of code.

This bug was caused by a few issues. First, when adding .dword
I decided to allow existing code to handle the fits within 32
bit case. The old code could not possibly handle that correctly.
Second, lengthinbytes = 8 was passed into the Memory system, given
that it takes an int as data and there are only 4 bytes in an
int it doesn't have defined behaviour for 8 bytes. Third, javas
shifting loops after 32 for integers. So in total, I failed to
account for a case, passed an undefined input into memory, which
resulted in replicated behaviour due to java.

I fixed it by just always handling the writes for .dword directly.

Significant postproccessing on these tests was needed to get them to
assemble. The test templates use a bunch of shifting and masking which
is not explanded by gcc when outputting assembly. Simpliying the
templates + sed to replace things automatically works pretty well, but
it also uses numbered branches which would force those to be rewrtiten
by hand. Also srl used C shifting logic to generate answers so that
needed to be done by hand.

In general, branches not included and very minor manual changes after
a small script post-processing and template changes.

… the same

Both jalr bugs apply to both rv32 and rv64, but only got caught
now because of the binary testing which allowed me to run the
riscv-tests that use special branching syntax RARS doesn't support.