The vectorisation and other improvements needed for the LibreSOC need a simulator in order to test out applications at the assembly-code / binary level, prior to implementation in hardware. An instruction-compatible simulator will be able to execute programs at reasonable speed whereas the hardware-level simulator will be hundreds of thousands of times slower. gem5 is a suitable starting point, and the modifications to spike (RV simulator) need to be ported to it: https://git.libre-riscv.org/?p=riscv-isa-sim.git;a=tree;h=refs/heads/sv;hb=refs/heads/sv see this: https://www.gem5.org/documentation/general_docs/architecture_support/
*** Bug 256 has been marked as a duplicate of this bug. ***
https://github.com/CSL-KU/SpectreGuard/blob/master/gem5/src/arch/power/isa/formats/integer.isa this looks reasonable to work with. it is a code-generator. so the hardware for-loop will go in as c code outputted as a c for-loop.
https://github.com/gem5-gpu also interesting however possibly as an aside. however texturisation and shader functionality were added.
https://github.com/cebix/macemu/blob/master/SheepShaver/src/emul_ppc/emul_ppc.cpp another powerpc emulator
http://pearpc.sourceforge.net/ another one to investigate
(In reply to Luke Kenneth Casson Leighton from comment #5) > http://pearpc.sourceforge.net/ > > another one to investigate pear is, honestly, looking a lot simpler to work with, although it's going to take some unit tests like those in riscv-isa-tests to get it into shape. see http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-March/005091.html to get whatever we need into shape it will go like this: * get "basic" (non-GUI) ability to run "bare-metal" programs. this involves either overloading a system call (writing one), peek/poke to a memory address and having the emulator say "writes to this address are directed to stdout, reads from this address result in characters from stdin being accepted". * start writing some *really* simple unit tests (20-50 lines of assembler) that test "addic", "mul", etc. etc. * begin the process of allowing dynamic (runtime) emulation of 64-bit instructions (not a static emulator-compile-time option) * *recompile* the unit tests using a 64-bit ppc compiler and test that those still work * start adding "basic" SimpleV support (a 48-bit instruction with the 16-bit "SV" Prefix) which does *NOT* support element-width. just a straight for-loop on integer math. * write unit tests - in assembler - for SVPrefix add, addic, mul etc. * move slowly forward adding full IEEE754 FP support (using Jacob's algorithmic library, so that we have *proper* POWER IEEE754 emulation, not "x86" IEEE754 rules) * add in elwidth support, predication, and so on, basically replicate the traillazing done in the spike-sv emulator. at the same time: * add support for dynamic LE and BE (unit tests for the same) * attempt to compile up more recent linux kernels, boot loaders (yaboot), in particular track down why Debian 8.0 PPC ISO cannot recognise (find) yaboot files on the ISO * see if the MMU (TLB) code is adequate to run a 64-bit OS * after the 64-bit bare-metal unit tests all pass, attempt to run larger programs and even a linux kernel. we *might* also want to consider porting the spike pk library to powerpc. it's a "bare minimum POSIX environment" which will allow the absolute bare minimum of POSIX applications to function. or, finding something else suitable to port.
https://github.com/lioncash/DolphinPPCTests https://github.com/JustinCB/macemu/blob/master/SheepShaver/src/kpx_cpu/src/test/test-powerpc.cpp Some Power unit test links.
thanks to hugh, he pointed me in the direction of this: https://github.com/power-gem5 it works however it leaks memory like a sieve
Revert mistaken change made to "budget (EUR) for this task, excluding subtasks' budget"
(In reply to Luke Kenneth Casson Leighton from comment #8) > thanks to hugh, he pointed me in the direction of this: > https://github.com/power-gem5 > > it works however it leaks memory like a sieve now fixed, upstream patches being submitted
commit 9078b2935beb4ba89dcd2af91bb5e3a0bcffbe71 (HEAD -> master, origin/master) Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net> Date: Fri Feb 12 14:41:48 2021 +0000 add srcstep and correct PC-advancing during Sub-PC looping in ISACaller first unit test operational
BEWARE some of the API changed with version 20.1 https://www.gem5.org/project/2020/10/01/gem5-20-1.html properties slave & master are changed to cpu_side_ports & mem_side_ports Others also.
(In reply to Alain D D Williams from comment #12) > BEWARE some of the API changed with version 20.1 > > https://www.gem5.org/project/2020/10/01/gem5-20-1.html > > properties slave & master are changed to cpu_side_ports & mem_side_ports > Others also. their mastery of the english language is second to none. i trust that they are not enslaved to the cult-like movement to eradicate history from living memory.
command-line ISACaller https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/pypowersim.py;hb=HEAD from Lauri: Please have it take multiple load- and save memory options instead of just one blob. --load file1 0x100 --load file2 0x500 --save out1 0x100 0x100 --save out2 0x500 0x100 - Lauri
https://github.com/phaa-eu/cavatools/tree/main/caveat a multi-process high speed simulator
forgot to account for budget assigned to bug #656
assuming lkcl intended to subtract eur 1200 for #665 the correct difference is 3700-1200=2500