Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The ability to generate a C library was lost in recent versions #720

Open
julienfreche opened this issue Sep 20, 2024 · 9 comments
Open

Comments

@julienfreche
Copy link
Contributor

In the past, we worked on the ability to generate a C library with Sail rather than a C executable. That was useful to use the generated code in the context of a full emulator or a VMM.

However, it looks like refactorings in the C backend eliminated that option. Was that on purpose and/or is there still a desire from the maintainers to keep this as a working option in the future?

For example, those changes were lost:
#81
#83
#164

@arichardson
Copy link
Contributor

I have used sail generated code as a library somewhat recently. For exxample: https://github.com/CTSRD-CHERI/cheri-compressed-cap/blob/master/test/contrib/sail_compression_128.c contains sail generated code that I used to compare against a C implementation of the same logic.
To generate it I used https://github.com/CTSRD-CHERI/cheri-compressed-cap/blob/master/test/regen_sail_c_code.sh: The flags -c -c_no_main -c_prefix sailgen_ -c_specialize seemed sufficient to get it working. That said those files are linked into a test binary rather than built as a standalone .so so it's possible there are some things that are broken.

@julienfreche
Copy link
Contributor Author

julienfreche commented Sep 20, 2024

Thank you for the quick reply and for giving this example. That's a start, but, it does not seem to cover a few features that are very useful to a VMM use case like:

  • Ability to override the read and write to the CPU registers as seen by Sail (useful to remap them to the actual registers and/or a shared state stored somewhere)
  • Ability to manually provide some function outside of sail (read or write to RAM for example)

or am I mistaken?

@Alasdair
Copy link
Collaborator

Maintaining two separate copies of the Sail C backend was too much work with the code duplication involved. I naively thought at the time that I could transition uses of the older C backend to the new one and fix the code duplication by removing the older backend, but that just wasn't realistic. When I switched the build system to dune (about 2 years ago roughly) and moved each Sail backend into a separate plugin, I wasn't sure if anyone was actively using the c2 output and it didn't fit neatly into the more cleanly separated architecture, so I decided to drop it - thinking that if anyone was they would probably notice and raise an issue. I see that finally happened!

My plan after that was to add these features back in by parameterising the original backend, preserving backwards-compatibility, but I just never had either the time or a pressing use-case to actually implement that.

@julienfreche
Copy link
Contributor Author

There is definitely an interest from our side as we still use sail to perform emulation in certain cases. I just only recently looked into upgrading our ARM model to a newer version hence the belated feedback. Thanks for the explanation.

@trdthg
Copy link
Contributor

trdthg commented Sep 26, 2024

We also have people here who are interested in Sail generating C libraries(with header file used for ffi calls)
maybe related to #215

@Alasdair
Copy link
Collaborator

Alasdair commented Oct 9, 2024

@julienfreche By the way, how do you feel about C++? I think I can do something quite a bit nicer (and easier) if I don't restrict myself to just plain C, i.e. rather than changing the compilation to thread all the state through manually I could make a C++ class that encapsulates all the state - that might be a nicer interface for using the model in general.

@julienfreche
Copy link
Contributor Author

We use C++ on our side so that would make my life even easier :) thank you for asking!

@arichardson
Copy link
Contributor

arichardson commented Oct 10, 2024

C++ would be much nicer! Last year I started trying to use the Boost.Multiprecision for the larger arithmetic, but never got around to fully implementing that. When profiling I saw that most of the time is being spent in malloc/free for GMP, and using a header-only C++ library would allow inlining all those functions to avoid heap allocations for smaller integers.

For example, https://godbolt.org/z/j3hjWhr4K shows that the compiler is able to remove all the logic to perform uint65 arithmetic whereas constant_fold_gmp still involves gmp API calls even for constants.

@julienfreche
Copy link
Contributor Author

julienfreche commented Oct 10, 2024

My experiments also correlate with your observations.

  • A lot of malloc/free that could fit on the stack
  • GMP is used for numbers that fit naturally the native CPU capabilities.

Tackling those two issues to some degree would lead to much better perf.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants