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:
*** Bug 256 has been marked as a duplicate of this bug. ***
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.
also interesting however possibly as an aside. however texturisation and shader functionality were added.
another powerpc emulator
another one to investigate
(In reply to Luke Kenneth Casson Leighton from comment #5)
> 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.
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.
Some Power unit test links.
thanks to hugh, he pointed me in the direction of this:
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:
> 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 <email@example.com>
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
properties slave & master are changed to cpu_side_ports & mem_side_ports
(In reply to Alain D D Williams from comment #12)
> BEWARE some of the API changed with version 20.1
> 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
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
a multi-process high speed simulator
forgot to account for budget assigned to bug #656