sail-riscv
sail-riscv copied to clipboard
riscv
Is there a good reason why some of our external libs are fetched dynamically and some are just part of the repo? We have softfloat and are about to add CLI11 as well now as part of the repo.
Is there a good reason why some of our external libs are fetched dynamically and some are just part of the repo? We have softfloat and are about to add CLI11 as well now as part of the repo.
Originally posted by @nadime15 in https://github.com/riscv/sail-riscv/pull/1161#discussion_r2226633367
I guess it's because by default we use the system libgmp, but the others are unlikely to already be available in package managers.
Arguably we could vendor libgmp too and just always use the vendored version... but really my long term plan is to implement a replacement that only provides the functions that Sail actually uses and is also much faster for small integers. I haven't got too far implementing that though.
The "proper" solution here is probably vcpkg but it's a whole extra thing to install and learn which kind of sucks. Or I guess if git ever gets some submodule-like solution that doesn't suck as much as actual submodules.
IMO vendoring is the least bad of several bad solutions.
I guess it's because by default we use the system libgmp, but the others are unlikely to already be available in package managers.
Arguably we could vendor libgmp too and just always use the vendored version... but really my long term plan is to implement a replacement that only provides the functions that Sail actually uses and is also much faster for small integers. I haven't got too far implementing that though.
The "proper" solution here is probably
vcpkgbut it's a whole extra thing to install and learn which kind of sucks. Or I guess ifgitever gets some submodule-like solution that doesn't suck as much as actual submodules.IMO vendoring is the least bad of several bad solutions.
By default build_simulators.sh will download and build libgmp. To use a system installation of libgmp, run env DOWNLOAD_GMP=FALSE ./build_simulators.sh instead.
Right. If you just run cmake it won't though. It's on by default in build_simulators.sh but not in CMake.
I guess it's because by default we use the system libgmp, but the others are unlikely to already be available in package managers.
Arguably we could vendor libgmp too and just always use the vendored version... but really my long term plan is to implement a replacement that only provides the functions that Sail actually uses and is also much faster for small integers. I haven't got too far implementing that though.
The "proper" solution here is probably
vcpkgbut it's a whole extra thing to install and learn which kind of sucks. Or I guess ifgitever gets some submodule-like solution that doesn't suck as much as actual submodules.IMO vendoring is the least bad of several bad solutions.
I'd quite like to just use something like https://github.com/boostorg/multiprecision which is all header only so the compiler can inline all the known-width code and avoid slow paths. Sail now generates C++ compatible code we'd just need to replace gmp with boost to get a large performance win.
The performance problems come from integers / bit-vectors that Sail doesn't know the size of though (or a fixed maximum size), so I think to get good performance we need something that works at runtime. The obvious think is something like
struct {
unsigned bits;
union {
uint64_t inline_value;
gmp* pointer_to_some_big_value;
}
}
And then I was thinking you combine that with arenas for 128 and 256-bit values, and finally fall back to malloc.
(Bit off topic sorry)