M vs. UM - An introspection into the future.

ewaller · 2012-04-09 19:02:52

holland01 wrote:

Just out of curiosity, why straight C?

Heap managers can be primitive, at best, on embedded systems. I've worked on many systems where there are no malloc provisions at all. On really simple systems where things must be deterministic, things often live on the stack, or are statically allocated.

On systems without an OS that do implement malloc, blocks are allocated from a chunk of memory in which the required number of bytes must be found in a contiguous block. Without the use of Handles (pointers to pointers) those data cannot be moved around to remedy a fragmented memory space. Without virtual memory or a MMU, and with characteristically small space that can be allocated to a heap, the task of creating a reasonable heap manager becomes next to impossible.

Without a good memory allocation system, C++ is hopeless. (Unless the plan is to just not use objects, but then, what is the point?) Use of the STL is out of the question. So are managed languages such as Java and C#. Interpreted languages are out of the question.

Note that I am talking about things that are not considered to be general purpose computing devices. I am talking about motor controllers, servo systems, brake controllers, safety interlocks and other things that use a processor that must work, and must be deterministic in their behavior. It also includes things like mice, keyboards, toasters, ovens, coffee makers, electronic locks, and other appliances.

Someone once said that C is nothing more than a universal assembler. Someone else said they may be right, but it is a darned good one. I tend to agree on both counts.

Last edited by ewaller (2012-04-09 19:03:45)

Arch Linux

#26 2012-04-09 19:02:52

Re: M vs. UM - An introspection into the future.

Board footer