Description
Where to find it
The bugfix-2.0.x-new-layout branch is a refactoring of the Marlin 2.0 codebase which includes the 32-bit HAL.
I'll be doing the meticulous work in my bugfix_refactor_work branch, and will make sure to keep the bugfix-2.0.x-new-layout branch in a working state for testing. Please report if it isn't compiling and I will aim to fix it quickly!
Development roadmap
The intent is to produce a more logically organized and granular codebase, encapsulate globals and their related g-code handlers into static singletons, by feature, and produce a codebase that will be easier to extend. As a refactor, the code size, logic, and performance is meant to remain unaltered. However, in practice, the inlining, linking, and calling behavior is bound to change. Please report any major changes in performance.
As this code develops, you may find things about it bothersome. This code will continue to develop and improve largely according to your feedback. Nothing in the branch is written in stone, and all ideas are welcome.
Initial status
As of this writing the branch has been through a couple of iterations, and it compiles successfully for both Arduino IDE and PlatformIO, giving a near-identical binary as the current "flat" codebase. The g-code handlers are split out into .h files to start to encapsulate them into units, by feature, where possible. This initial breakup into .h files was a good first step, as the main thing was to produce a new layout that could compile but without making any functional change to the firmware. This is proving a useful organization from which to go forward with the next step…
Static classes, namespaces
We don't have to sacrifice compiler optimizations such as inlining smaller handlers just because we move things into .cpp files, so long as all the g-code handler code is encapsulated into static singletons. The smaller inline-able methods can be defined in the .h files of the new singletons, while the bigger handler functions that only bloat the process_next_command function can be static.
The G-code handlers can be moved into singletons by an almost automatic process, taking each G-code handler now inside an .h file and doing a quick refactor…
- Rename the
.hto.cppfile and compile to see where it fails, citing dependencies. - Bring in the needed
externand#includelines to resolve the dependencies. - In some cases shift the definition to the g-code handler files, or added headers.
By doing this in groups of G-codes that all relate to the same config option, they can then be grouped into a singleton class, any feature-related globals and functions currently defined in Marlin.cpp will be moved to the new singleton class. Any functions they share with other config features can be encapsulated in a shared friend class.
The static class instance has been chosen rather than pure namespaces because they provide some extra features and syntactic sugar. The instances are superfluous, but allow us to use dot-notation to access class data. (planner.something() does the same as Planner::something()).
Parallel Development
As long as most development and bug-fixing to bugfix-2.0.x focuses on the HAL, I can continue to refine the G-code handling code and restructure this branch without disrupting that work. As long as patches made to Marlin_main.cpp and other files are straightforward, they shouldn't be hard to bring into the refactored branch, as the intent is only to reorganize and not, largely, to modify the code.
Branch Cleanup
To make it easier to follow changes, I will re-build the bugfix-2.0.x-new-layout commits again except this time I will move all the files, unchanged (except renames), to their new locations, and only afterward apply all the textual changes to the files. That set of textual changes will be primarily to the #include lines, so it should make a nice picture of how dependencies are affected.
Timetable
- 6 Sept: Rebuilt branch commits, identical to current time (5 Sept)
- 7 Sept: Some G-code handlers refactored into feature singletons.
- 9 Sept: Consolidate motion, kinematics, leveling, etc.
- 12 Sept: Complete handler refactoring.
- Oct-Nov: Refactor LCD and other code as static singletons, as appropriate
@MarlinFirmware/32bit-maintainers