Hiffy size improvements for stm32g0 I2C #1541
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cbiffle
force-pushed
the
oxcon2023g0-hiffy
branch
from
99311b0 to
1670298
Compare
mkeeter
reviewed
Sep 18, 2023
mkeeter
reviewed
Sep 18, 2023
cbiffle
force-pushed
the
oxcon2023g0-hiffy
branch
from
1383d9f to
0cdc878
Compare
cbiffle
force-pushed
the
oxcon2023g0-hiffy
branch
from
0cdc878 to
cbf3ce7
Compare
The generic send and send-with-lease operations currently add 1456 bytes of text, so we can either have these _or_ I2C on 32 kiB parts. I haven't made them optional on other targets yet because, frankly, those targets haven't needed it.
This knocks 256 bytes off I2C support (text), so we can potentially enable it on G030. More savings are potentially available in this code, and we've got a lot of duplication across targets that means we can probably save space on other machines as well. The techniques applied here: 1. Find larger chunks of repeated code and factor them into a common routine (the i2c_args -> i2c_args_to_device transition) 2. Find duplicate checks for things like bounds or slicing and make them occur in only one place, reusing the result. (e.g. when slicing like buf[..n], we can assign the result to a variable and reuse it -- and we can combine this with the check by writing buf.get(..n).) 3. Find unhandled integer overflow cases and convert them to more graceful failures (currently, clients can trivially crash Hiffy by sending large integers for many parameters; this reduces their number) 4. Apply shared subexpression elimination to things like the frame pointer / base pointer calculation in the write routine. Previously they were computed separately, which didn't make it clear to the compiler that they're trivially related, causing it to generate excess checks. I've also applied a lot more 'ok_or' and '?' patterns to remove a lot of manual match statements on errors, under the theory that the size of the code on the page ought to more accurately reflect its importance/complexity in the domain (I2C). I think this change makes the actual sources of complexity more apparent.
cbiffle
force-pushed
the
oxcon2023g0-hiffy
branch
from
cbf3ce7 to
9530dd5
Compare
|
@mkeeter this should be ready to go |
mkeeter
approved these changes
Sep 19, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This applies two changes to make Hiffy practical on the 32 kiB STM32G030, with I2C support enabled. As usual there are verbose details in the commit messages, but in summary,
Note that, at the time this PR was created, this was blocked on a HIF PR: oxidecomputer/hif#6