You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+27-11Lines changed: 27 additions & 11 deletions
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ which makes it suitable for use in high-integrity embedded systems.
16
16
17
17
The codebase is implemented in C99/C11 following MISRA C:2012, with several intended deviations which are unavoidable
18
18
due to the fact that a memory allocator has to rely on inherently unsafe operations to fulfill its purpose.
19
-
The codebase is extremely compact (<500 SLoC) and is therefore trivial to validate.
19
+
The codebase is extremely compact (<500 LoC) and is therefore trivial to validate.
20
20
21
21
The allocator is designed to be portable across all conventional architectures, from 8-bit to 64-bit systems.
22
22
Multi-threaded environments are supported with the help of external synchronization hooks provided by the application.
@@ -77,9 +77,9 @@ a memory allocation request even if there is enough free memory due to its subop
77
77
By definition, if the amount of memory available to the allocator is not less than *H*, then the state of
78
78
catastrophic fragmentation cannot occur.
79
79
80
-
Memory allocators used in general-purpose (nonreal-time) applications often leverage a different class of algorithms
80
+
Memory allocators used in general-purpose (non-real-time) applications often leverage a different class of algorithms
81
81
which may feature poorer worst-case performance metrics but perform (much) better on average.
82
-
For a hard real-time system, the average case performance is generally less relevant
82
+
For a hard real-time system, the average case performance is generally less relevant,
83
83
so it can be excluded from analysis.
84
84
85
85
The above-defined theoretical worst-case upper bound H may be prohibitively high for some
@@ -90,7 +90,7 @@ the probability of a (de-)allocation sequence that results in catastrophic fragm
90
90
When combined with an acceptable failure probability and a set of adequate assumptions about the behaviors of
91
91
the application, this property may allow the designer to drastically reduce the amount of memory dedicated to
92
92
the heap while ensuring a sufficient degree of predictability and reliability.
93
-
The methods of such optimization are outside of the scope of this document;
93
+
The methods of such optimization are outside the scope of this document;
94
94
interested readers are advised to consult with the referred publications.
95
95
96
96
Following some of the ideas expressed in the discussion about memory caching in real-time systems in [Herter 2014],
@@ -173,15 +173,18 @@ and its internal data structures are not damaged.
173
173
174
174
### Build configuration options
175
175
176
-
The preprocessor options given below can be overridden (e.g., using the `-D` compiler flag, depending on the compiler)
177
-
to fine-tune the implementation.
176
+
The preprocessor options given below can be overridden to fine-tune the implementation.
178
177
None of them are mandatory to use.
179
178
179
+
#### O1HEAP_CONFIG_HEADER
180
+
181
+
Define this optional macro like `O1HEAP_CONFIG_HEADER="path/to/my_o1heap_config.h"` to pass build configuration macros.
182
+
This is useful because some build systems do not allow passing function-like macros via command line flags.
183
+
180
184
#### O1HEAP_ASSERT(x)
181
185
182
186
The macro `O1HEAP_ASSERT(x)` can be defined to customize the assertion handling or to disable it.
183
187
To disable assertion checks, the macro should expand into `(void)(x)`.
184
-
185
188
If not specified, the macro expands into the standard assertion check macro `assert(x)` as defined in `<assert.h>`.
186
189
187
190
#### O1HEAP_LIKELY(x)
@@ -195,7 +198,7 @@ or into the original expression `(x)` if no such hinting is desired.
195
198
If not specified, the macro expands as follows:
196
199
197
200
- For some well-known compilers the macro automatically expands into appropriate branch weighting intrinsics.
198
-
For example, for GCC, Clang, and ARM Compiler, it expands into `__builtin_expect((x), 1)`.
201
+
For example, for GCC, Clang, and ARM Compiler, it expands into `__builtin_expect((x), 1)`.
199
202
- For other (unknown) compilers it expands into the original expression with no modifications: `(x)`.
200
203
201
204
## Development
@@ -204,9 +207,7 @@ For example, for GCC, Clang, and ARM Compiler, it expands into `__builtin_expect
204
207
205
208
The following tools should be available locally to conduct library development:
206
209
207
-
- GCC v9 or newer.
208
-
- Clang and Clang-Tools v9 or newer.
209
-
- CMake v3.12 or newer.
210
+
- Modern versions of CMake, GCC, Clang, and Clang-Tools.
210
211
- An AMD64 machine.
211
212
- (optional) Valgrind.
212
213
@@ -223,6 +224,10 @@ Compliance is enforced through the following means:
223
224
224
225
Please refer to the continuous integration configuration to see how to invoke the tests.
225
226
227
+
### Releasing
228
+
229
+
Update the version number macro in the header file and create a new git tag like `1.0`.
230
+
226
231
### MISRA compliance
227
232
228
233
MISRA compliance is enforced with the help of the following tools:
@@ -252,6 +257,17 @@ An exception applies for the case of false-positive (invalid) warnings -- those
252
257
-[Dynamic Memory Allocation In SQLite](https://sqlite.org/malloc.html) -- on Robson proof and deterministic fragmentation.
253
258
-*[Russian]*[Динамическая память в системах жёсткого реального времени](https://habr.com/ru/post/486650/) -- issues with dynamic memory allocation in modern embedded RTOS and related popular misconceptions.
254
259
260
+
## Changelog
261
+
262
+
### v2.0
263
+
264
+
- Remove critical section hooks to enhance MISRA conformance [#4](https://github.com/pavel-kirienko/o1heap/issues/4)
265
+
- Add support for config header via `O1HEAP_CONFIG_HEADER`[#5](https://github.com/pavel-kirienko/o1heap/issues/5)
266
+
267
+
### v1.0
268
+
269
+
The first release.
270
+
255
271
## License
256
272
257
273
The library is available under the terms of the MIT License.
0 commit comments