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.
