| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This fixes various annoyances in our clang-format style that have been
bothering me for a while:
* Binpacking arguments/parameters and aligning them to the opening `(`
is *really* bad for diffs/conflict resolution. This changes it to try to
match the "prettier" algorithm (also used by Sail's autoformatter),
which has much simpler and better behaviour - if the arguments fit on
one line do that, otherwise put each argument on its own line.
* Don't put functions on one line. This is also a little diff-unfriendly
and feels unnecessarily inconsistent to me.
* The line length limit of 80 characters is very constrictive so I
increased it to 120 characters.
* For some reason it didn't put `{` on a new line... except for function
bodies, which is weirdly inconsistent. Now `{` never starts on a new
line.
* Sort `#include`s. This might have been needed in the past but I
verified it builds with sorted includes now.
|
|
This switches from using Sail's C output to using C++. The output code
gets wrapped in a `class`, which means we can create more than one
instance of it (e.g. for multicore).
The `Model` class is currently *not* thread safe due to the use of
temporary globals in `sail.c`. So although you can simulate multicore
systems, you have to execute them one at a time.
The handling of platform callbacks is a little convoluted but I think
this is a quite flexible solution. Sail is instructed to derive the
`Model` class from `PlatformImpl` which has virtual methods for all of
the platform callbacks with default nop implementations.
This means the default `Model` can be constructed and has a "nop"
platform. Then we add our implementation of the platform with
`ModelImpl` which overrides those methods.
`ModelImpl` also allows registering callback receivers.
This is not 100% perfect yet. We still have a global `g_model`, which is
not ideal.
---------
Signed-off-by: Tim Hutt <tdhutt@gmail.com>
Co-authored-by: Tim Hutt <timothy.hutt@codasip.com>
Co-authored-by: Nadime Barhoumi <nadime@riscv.org>
|
|
Split the config_print_platform to five options:
- config_print_clint
- config_print_exception
- config_print_interrupt
- config_print_htif
- config_print_pma
The main problem with a single option was CLINT mtime: when a hart is
halted in debug mode, it keeps printing the CLINT time, even though
nothing is happening.
Fixes #1340
|
|
Default to `stdout` and avoid doing an assignment inside an
if-expression.
|
|
`nullptr` is C++-only but is slightly more type safe than NULL.
|
|
The validation is done at run-time; build-time validation is not handled
here. The schema is always validated for all configurations for
simplicity and safety.
This uses the jsoncons library which is added as a dependency.
---------
Co-authored-by: Ariel Xiong <ArielHeleneto@outlook.com>
|
|
It is too easy to miss adding each one in multiple places. This should
go away once the compiler can generate them as part of `model_init()`.
|
|
Rather than having vlenmax (64kb) sized vector registers and only using
part of them, just allow configuring vlen directly.
|
|
This adds basic support for Sail unit tests. These have some pros and
cons over C tests:
Pros:
* They don't require a RISC-V C compiler.
* They can test internal code (hence why I've called them unit tests).
* They can "cheat", e.g. to change privilege mode you can just magically
`cur_privilege = Supervisor`. With C you have to implement a syscall,
etc.
Cons:
* They are tied to internal code which will make refactoring more
tedious because it means you are likely to need to update the tests. We
can minimise that by using "high level" functions like `execute()`,
`read_CSR()`, etc.
* They only run on the Sail model, so we can't e.g. verify them against
SPIKE.
Given the sorry state of testing in this repo, and the fact that we
don't have a way of writing C tests at all yet, I think this is probably
a good medium term approach.
Currently the unit test executable reuses a load of code from the
emulator, which is not ideal. When we have wrapped the model in a nice
C++ library we can use that instead.
|
