which object orient language is most suitable for embedded programming?

For many embedded systems, that's all that needs to be done. But for others (for example, the ColdFire system I am using at the moment), you need to set up the memory before you can access the ram. These things can be highly dependant on the particular board - you can't just use the startup code that comes with the compiler.

Then you won't crash. I did say "if .... otherwise ....".

--
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.

Chris what capability would you like added in typedef or a new keyword (god forbid)?

-- Walter Banks Byte Craft Limited

For me, it would be for typedef to create something stronger than an alternative name: In C++, I use the following:

template class TypesafeWrapper { public: TypesafeWrapper(); explicit TypesafeWrapper(Type value);

Type & Value(); Type Value() const;

private: Type value_; };

Then I can do: typedef TypesafeWrapper Weight; typedef TypesafeWrapper Length;

Length l = x; Weight w = y;

so the compiler will not let me do: l = w;

I could do "l.Value() = w.Value()" if I was that determined but at least the compiler can help spot the obvious mistakes.

Ideally, some form of "typedef unsigned Length" would accomplish this (afterall, there are cases where using typdef to create a short name for something else is useful).

--
Paul

Walter, your earlier post suggested that you were interested in OOP extensions. I had some thoughts of my own about what would help C in embedded use, but they weren't strictly aligned as I read your earlier query. But now I'm wondering if you are open to a wider range, or not.

What are you imagining here? Is this something that may play into participation with improving an embedded C standard? (Which is much broader question than OOP-only.) Or?

Jon

Lint (PC-Lint anyway) will give you this already. One of its more valuable features.

Robert

--
Posted via a free Usenet account from http://www.teranews.com

It's late, so will be quick and think about this to perhaps add more later,

typedef enum, for example, produces a range of values which are (Harbison & SteelE) of type int. If you have a small range of values and want to declare a variable, for example:

typedef enum {OK, DODGY, FAIL} STATUS;

Then:

STATUS eStatus = OK;

The variable takes on the type int. If you are fussy about types and want to use the range of values economically in, say, an unsigned char, it all gets to feel quite untidy. Some compilers have switches to select

8 or 16 bit enums, but it's not a general solution.

So, how about:

typedef enum int ...

typedef enum unsigned char ... ?

Or similar. No added keywords, but the compiler then has the necessary info to do some real type checking...

Regards,

Chris

As I noted to an earlier suggestion, PC-Lint has this capability already. It won't reduce the sizes your compiler uses of course but it can complain if you assign a value of the wrong typr to eStatus (not just the wrong range, the wrong type).

The tools exist (and are reasonably economical), all that's required is the wherewithal to use them.

Robert

--
Posted via a free Usenet account from http://www.teranews.com

Compilers for ARM automatically select the right enum size depending on the range fo the values, so the user has full control over the selected type. It would be nice to standardise this - there are many similar bugs (some would call it "undefined" or "implementation defined" behaviour) in C and C++ that need urgent fixing.

While it seems a reasonable extension, compilers already have this info. But it's the enum type itself you want to check rather than the storage type. C++ has stricter enums which improves things a little.

Wilco

...

The overhead in terms of codesize and performance is extremely high for simple accessors - you replace a single load/store with a call that takes 5-10 instructions. I've measured huge overheads in C++ applications when either no functions were inlined (ie. not even the simple accessor functions), or all inline functions were inlined (ie. including the ones the user thought were a good idea to inline but actually weren't).

Many compilers can now do this without any cost. C++ demands smart inlining to make access methods and simple constructors zero overhead. C compilers often support similar inline keywords (which finally made it into C99 although with a different definition from C++ - just to make the life of compiler guys more interesting).

I wouldn't call this "exposing" - in C++ you can ensure a user cannot actually access private members, but in C you could document something to this effect. Whether (parts of) the implementation reside in a header or in a C file is a minor detail (you could just #include the C file rather than the header and still get access to the implementation) - what matters is the interface.

Wilco

gcc (for any target), and some other compilers, support minimal length enums if you specify a compiler option. But this is not standard C ABI, and thus could cause trouble if you are linking object files with different options. I believe that in C++, enums normally take minimal space (but an implementation can use a bigger underlying type if it wants).

Ideally, a C or C++ compiler should pick the smallest underlying type for static data, and the fastest underlying type for local variables (I'm thinking here that for many 32-bit cpus, using 8-bit data in registers is slower than 32-bit data as they have to have extra masking instructions).

A few other things could be added to the enum concept to make it vastly more useful. Some, like scope resolution, could be "back-ported" from C++. Other things that would greatly improve them would be a proper way to find the number of constants in an enum, and to be able to use them as indexes for arrays.

Jon,

There have been several ill-fated attempts at developing OO for embedded systems. This discussion has been more about OO and what it means and less about implementation in some specific language.

My first question is given a blank slate that starts with C what is needed to describe OO syntactically.

I don't have a specific agenda, there is a long way between ideas and standards. This is the develop the best idea phase and try some promising implementations.

w..

-- Walter Banks Byte Craft Limited

Chris

Good points.

It would be trivial to add to any of our compilers

In Byte Craft's implementation of enums is to analyse the arguments and choose a data type that can represent them.

8,16,24,32 bits signed or unsigned.

I have always been shocked at how weak enums are in C. My second enum issue is the list of values is not inclusive in your example I could declare legally

STATUS eStatus = 9;

Thanks

w..

... snip ...

That is not possible in C, because of the provisions for setting individual values for the enum constants. This is useful in creating single bit constants, for example. However it precludes proper range checking, as in Pascal. The sort of declaration that causes the incompatibility is:

enum errbits {NOERROR, ERR1, ERR2, ERR4 = 4, ERR8 = 8} anerror;

which allows signalling multiple errors by "anerror |= ERR2;" Changing to the Pascal style would invalidate existing code.

--
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.

Is there ever a case where a larger type makes sense, once the enum is used as an index ? - ie where code can be smaller/faster, if the typedef is made larger ?

Modula-2 has had Type Safe Enums for decades, shouldn't be too hard to allow C to have the same feature (without the band-aid PC-Lint )

Yes, it would have to be optional ....

-jg

Usually a full width register is part of an indexing expression, thus a zero extend instruction (or clear register/update byte) instruction would be needed to convert a byte value to 16 or 32 bit register width. However, with the enum 16 or 32 bit wide, the enum value could be directly loaded into the register.

For switch/case purposes, it would even make sense to only assign every 4th value (0, 4, 8 etc) for a 32 bit processor, simplifying jump table access.

If the enum type could be specified as uint_least8_t or uint_fast8_t would help to specify which kind of behaviour is expected.

Paul

A compiler could choose a larger type whenever feasible, eg. for global or local variables. On a 32-bit CPU it is common to upgrade char and short variables to 4 bytes. I've emitted

4-byte stores but 1-byte reads to access a char variable in cases where this isn't possible (eg. address was taken).

For structures I can't see a benefit of a compiler automatically choosing a larger size, most of the time people want structures to be as small as possible and have a predictable size.

Indeed, C was not meant to be type safe in any way or form... It's a shame that type safe languages always lose the nice (and necessary!) low level stuff along with the unsafe things - I don't believe it has to be that way in a well designed language.

Wilco

A load instruction will typically do this sign extension for free. On a CPU with mixed 8/16 or 16/32 bit registers (ie. x86), if you have an enum in a narrow register you would need sign extension, howevr a clever compiler could avoid this by keeping it in its widest form.

On Thumb jump tables are typically 8-bits per case... There is no advantage in using 32-bit jump tables on a 32-bit processor as the offsets are typically small.

Wilco

I would argue that if you're accessing the value sufficiently often for the overhead to be a problem, then either a) it's in the wrong module or b) cache it: read it into an automatic variable once early on (or store from an automatic late on). This is fine with synchronous code.

Hmmm. I strongly (as Jonathan noted) avoid placing private stuff in header files. The main reason is that I make a strong disitinction between interface and implementation. Another (somewhat less compelling) reason is makefiles: I've observed C++ people complaining of long build times, even with (admittedly large) embedded projects, and becoming wary of modifying public classes - if the header changes, and everything has that header as a dependency, I can understand the problem. For C++ to have private stuff in public headers is in my view just plain broken ;).

Steve