Optimisations

[prandeamus]

I sense it may not be your top priority but would you be interested in a few small-scale optimisations that would save a few bytes in the bootloader code? I've found a few cases where small edits in C code yield savings. I can't pretend to have done a full test in all your test rigs but will do what testing that I can and submit PRs.

Generally: In a device the size of a Tiny 85, bytes do count. Are the page boundaries significant? That is, if I save a handful of bytes but timonel still occupies the same number of flash pages, is there a direct benefit?

[prandeamus]

I've submitted a pull request that saves up to 16 bytes on a full image (depending on what options are enabled). These have been tried informally but no doubt you can do more testing than I can.

I can see a few other ideas to reduce the code size, without having to drop down assembler. If you find this sort of thing useful, I can continue to submit pull requests on an optimisations branch, or whatever works for you.

[casanovg]

I sense it may not be your top priority but would you be interested in a few small-scale optimisations that would save a few bytes in the bootloader code?

Of course I'm, every single byte counts for a bootloader.

I've found a few cases where small edits in C code yield savings. I can't pretend to have done a full test in all your test rigs but will do what testing that I can and submit PRs.

Sounds good, let's try it ...

Generally: In a device the size of a Tiny 85, bytes do count. Are the page boundaries significant? That is, if I save a handful of bytes but timonel still occupies the same number of flash pages, is there a direct benefit?

If the savings would stretch out 1 page, that's would be obviously great. But, sometimes little savings also count since there are lots of possible feature combinations. Maybe a change saves only 4 bytes, but sometimes that's enough to get back a full page if, for instance, you disable the memory dump and LED UI features, to name a few.

I've submitted a pull request that saves up to 16 bytes on a full image (depending on what options are enabled). These have been tried informally but no doubt you can do more testing than I can.

OK! I will merge it and test it. Just a little detail, please work on the v1.6 branch as that's the one I'm working on as well to prepare for its release. I plan to merge v1.6 with the master branch two to three weeks from now. If you make changes to the master, I have to replicate them in v1.6 as well to avoid losing them in branch merging, which duplicates the work. Is it OK for you?

I've submitted a pull request that saves up to 16 bytes on a full image (depending on what options are enabled). These have been tried informally but no doubt you can do more testing than I can.

Sure, I'll test it on various chips. If I find problems, I will let you know.

I can see a few other ideas to reduce the code size, without having to drop down assembler. If you find this sort of thing useful, I can continue to submit pull requests on an optimisations branch, or whatever works for you.

Yes, you are welcome to introduce any idea you can think of to improve this software. About including assembler, although I like it, for the moment I would prefer to stick with C as much as possible since it's more accessible to many, easier to maintain, and simpler to port to other platforms.

[prandeamus]

All noted. I'll let you know how I get on.