The new code always keeps harts in consistant states, so it's no longer
necessary to track their states manually.  There's still some flakyness
with halt/resume over breakpoints.

This new version changes how we handle temporary registers: rather than
tracking them by hand (like in the old code), they're now tracked as
part of assembling programs.  The register save/restore assertion that
used to fire all the time no longer exists.

This assumes that v0.11 targets have one hart, and that v0.13 targets
have harts IDs that start at 0 and are concecutive.

This is a work in progress, but it's at the point where you can actually
debug multi-hart programs now.

Readmem autoexec

riscv: Use write-1-to-clear for CMDERR, not write 0 to clear.

This reverts commit 466b7b48.

Read memory retry

riscv-v13: wait for idle in read_memory

read_memory was doing autoexec-initialized commands, but wasn't using
ac_busy_delay to add delay or wait between the commands. This isn't the optimal
solution, but the whole read_memory sequence needs to be made more efficient
anyway, so this was the quick and dirty solution.

Change-Id: I24d545cc259927301851fad446f812e95fd1c557

riscv: Ensure that hart is halted before attempting to examine it.

Change-Id: I3a370aa3a478ab84c9b2afff7b3f581bd7dc5e06

Replace the constants with the ones from the ISA spec, since those are
not updated as often.

Also delete a bunch of old code.

Change-Id: I9201b1455d64a9d2d203bb362fefaa68cbf35aeb

Change-Id: Ib09e1da81c6c0e7c9c6b69e9fe31eda20e3cd6e0

The remote bitbang implementation is really slow when reading back data.
During many operations, like writing a block of memory, we don't need to
see the return data. By communicating this to the lower layers, we get
huge speedups. Downloads to spike now are 295KB/s.

That means the gdbserver.py download test now runs to completion,
unfortunately it fails. Everything else is still passing, though, so I'm
committing this change.

Change-Id: I44cc9db1ade0908c1a12d09b23fc8e529a802d88

To spike now we download at 5KB/s. But in real hardware performance
should be pretty OK now.

Change-Id: Ie6086cf156c9a00ac55400870346e27b28e3c755

Change-Id: I985afa433a09f833137f2e244b7eaad2630f6b1a

Now 33/39 of the gdbserver tests pass!

Change-Id: I0cb38fbbcdc2c037ff0ec77229e79f24fa021663

Not a great fix. There's still a problem with accessing 64-bit floating
point registers on 32-bit cores.
24 of the gdbserver.py tests pass now.

Change-Id: I69a88ef5fd5581e2c7bf1d78057fd474ae86ff93

23 gdbserver.py tests pass now.

Change-Id: I32805d615ae5f536f179baf906e0e74a56e80c0b