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

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.