or1ksim64ptb Files

These patches are all to the same or1ksim-or1k-master branch of the
or1ksim-or1k openrisc simulator code, approximately as it stood at May
4 2014:

   https://github.com/openrisc/or1ksim

The last mods to my working base were made by Stefan Kristiansson on
2014-05-04, according to the Changelog.  That should help you identify
the version to which these patches apply cleanly as the or1ksim
repository evolves in the future.

Stefan has a git repository of the or1ksim source code with these
64-bit patches already applied at

   https://github.com/skristiansson/or1ksim/tree/or1ksim64

That may - or may not - integrate my most uptodate patch.

The support I've provided is for the 64-bit part of the OpenRISC
specification at http://opencores.org/or1k/Architecture_Specification.

As of 16/1/2014 you configure with
        --target=or64
in order to prep for compilation as a 64-bit simulator.  Without that
you get the standard 32-bit simulator.  Try make with
        EXEEXT=64
as an extra argument to get "64" added to the names of the compiled
executables. That avoids confusion.

Before 16/1/2014, compilation gave you the 64-bit simulator whatever you
did at configure time, replacing the standard 32-bit simulator compile.

Each patch here in the "patches" subdirectory is a "better" attempt than
the previous one, and you should choose which to apply to the or1ksim
base.

The "incremental" subdirectory contains patches from one patched version
of or1ksim-or1k-master to the next, and should be applied successively.

Peter Breuer 15/1/2015

28/12/2014 initial patch, changing register sizes, address sizes,
           adding working sd, ld implementations as well as 64-bit
           integer arithmetic everywhere. Pretty much all tests (make
           check) still work, but the results are often different,
           causing a formal fail, which really reflects a test bug
           since the arithmetic I've checked line by line is correct
           (e.g. the "basic" test gives the wrong final report, but
           that's really what it should give given its code - somebody
           needs to modify the expected test results for 64-bit!).

4/1/2015   fixes to 64-bit arithmetic following the spec instead of my
           head, and more arithmetic operations implemented in 64-bit,
           particlarly the "mac" -style instructons (which I had never
           heard of before).  More tests "fail" now, but that may
           reflect that they need to be fixed for 64-bit.

14/1/2015  add ability to parse ELF64 files, which are really needed if
           one expects to run 64-bit!  If somebody could fix the
           compiler to generate some, that would be fine and I could
           test.
           
           NB: ELF32 executables still make sense loading in 64-bits,
           but signed constants will be interpreted as lying in the
           range of the first 2^31 and last 2^31 values in a 64-bit
           range, which may or may not be what you expect.
           
           Unsigned constants will be interpreted as lying in the rage
           of the first 2^32 values in a 64-bit range.  Ditto for
           addresses.
           
           Nobody has checked for sign problems in the 64-bit context
           for 32-bit addresses re-interpreted there, so they'll
           probably go fairly randomly top or bottom if the 32-bit sign
           bit is set - try to keep them in the lower half of 32-bit
           address space for safety.

16/1/2015  Split compilation paths so you need --target=or64 at
           configuration, which sets OR64 and compiles a new cpu/or64
           subdir instead of cpu/or32.

18/1/2015  Mended the "transl_table" virt/phys translation in parse.c
           to cope with 32- or 64-bit entries, even though it is 
           never used at present. Entry format is now oraddr_t+oraddr_t
           plus 64 bits of flags. It was uint32+uint32 plus 64 bits of
           flags.

           Completed changes with respect to compile path split.

24/1/2015  Cosmetic issue in cpu/or64/Makefile.am.

31/1/2015  Correct typing issue for signed 16-bit promotions of
           instruction immediate data originating with generate64.c.

04/2/2015  Make all read/writes to real memory in memory.c pass through
           the 64-bit read/write functions when compiled for OR64.
           This is inefficient, but makes physical memory transfers
           easier to intercept.

           Ditto 32-bit when compiled otherwise.

08/2/2015  Change the dcache to use 64-bit read/writes to memory
           instead of 32-bit read/writes when compiled for OR64.

09/2/2015  Implement 64-bit vector operations (msubs not done, because
           its spec is noted as inconsistent; ditto madds;  maybe
           I got pack/unpack and perm_n wrong, also some of the
           "saturated" arithmetic instructions - tests needed).

10/2/2015  Correct l_ff1 and l_fl1. Correct most single precision
           floating point operations to work well with compilation
           for OR64 too (by casting params and results assiduously).
           Implement double precision floating point operations.
           Fix compiler complaints in vector op implementations.

11/2/2015  Correct 64-bit byteswapping macro in elf.h for 64-bit files.
           Split memory path for instructions and data in memory.c
           so that the addprogram() call in parse.c goes through
           the instruction path, not the general data path.  This is
           a "Harvard architecture".

18/2/2015  Split out an softint.c from insn64.c to wrap integer ops
           to allow those native ops that are missing to be programmed
           in systematically in detail rather than done ad-hoc in situ
           in insnset.c.  Analogous to softfloat.c.

28/2/2015  Add muld and muldu instructions. Encapsulate displacement
           address calculation using add() functions. Improve mul and
           mulu implementations.