Software Integrity Ltd

Following on from previous postings, here is a UML diagram showing two classes concerned with dynamic memory handling: Read more…

Today’s post is about the strategy of dynamic memory handling in SKC++.

Last time, I recommended a short slide presentation for perusal. I will not repeat here what that says, except to quote the last slide:

Preventing fragmentation
• Always use pools, never heaps
– Exception: memory which is never intended to be freed can be taken from a heap
• Override the global new() and delete() operators
• Consider per-class new() and delete() operators
– Quicker, as well as safer

In a nutshell, that is the strategy for SKC++. Read more…

I have been thinking about SKC++ for longer than I have been blogging about it and dynamic memory allocation should not have been my first topic. Before all else, I should have taken the trouble to explain SKC++ in more general terms. I’ll do it now… Read more…

Today, I am working on the dynamic allocation scheme for SKC++. It’s very simple (as everything is supposed to be in SKC++), so it won’t be long before I post again, reporting on progress.

In the meantime, if you’re wondering what’s wrong with using the standard new and delete mechanisms that come with C++ I urge you to have a look at my short slide presentation on the subject. The last two slides are particularly important.

Till soon…

Most of today’s RTOS offerings are too complicated. Here are some reasons why this is so:

• Insufficient thought , before designing, as to what is really essential and what is not, leading to redundancy and confusion.
• The perceived need to offer everything already offered by competitors, then to add more features in an attempt to steal a march on them.
• The fact that some products, as in all walks of life, are just badly designed. Unfortunately, the power of heavy marketing to foist mediocre products onto customers has been proven over and over again.
• The fact that some people, including software designers, have a natural tendency to complicate rather than simplify. This, I’ve noticed, happens particularly with younger engineers who are anxious to shoehorn everything they know into a project rather just what’s needed. I probably did some of that, too, but it’s so long ago that I can’t remember!

Well, I’m bucking the trend by writing what I believe will be a simpler and better pre-emptive kernel Read more…

As you can gather, I have just started this blog, which is an extension of Software Integrity’s main website. I will be airing many topics here, but all in the field of Real Time and Embedded Software.

I hope you will find it interesting and I welcome your feedback on the articles I post here.