embedded or real-time project using Eiffel

Hi all,

does anyone know of an embedded or real-time project out there which is
using Eiffel? I've heard of HP using Eiffel for their printers (see
http://archive.eiffel.com/eiffel/projects/hp/creel.html), but it seems
this information is a little outdated.

What is your experience with performance of Eiffel programs in terms of
memory footprint and execution speed?

Daniel

> does anyone know of an embedded or real-time project out there which is
> using Eiffel? I've heard of HP using Eiffel for their printers (see
> http://archive.eiffel.com/eiffel/projects/hp/creel.html), but it seems
> this information is a little outdated.

Eiffel Software still provide a customized version of its runtime that
targets embedded devices. This runtime is customized to match your
requirements (I/O, type of GG/memory allocation, ...) so that you can
reduce the memory footprint.

> What is your experience with performance of Eiffel programs in terms of
> memory footprint and execution speed?

Depending on the platform, the size of the executable usually fits in
less than 256KB (possibly much less but it actually depends on how much
code you write) and less than 256KB (possibly much less but again it
depends on how many objects are alive during execution). For execution
performance, it is roughly the same as what you will get if your code
was written in C but using Eiffel you get the benefit of clearer code,
code reuse and contracts.

Regards,
Manu

------------------------------------------------------------------------
Eiffel Software
805-685-1006
http://www.eiffel.com
Customer support: http://support.eiffel.com
User group: http://groups.eiffel.com/join
------------------------------------------------------------------------

On 18 Feb., 19:15, Daniel Klünder <kluen...@cs.rwth-aachen.de> wrote:
> Hi all,
>
> does anyone know of an embedded or real-time project out there which is
> using Eiffel? I've heard of HP using Eiffel for their printers (seehttp://archive.eiffel.com/eiffel/projects/hp/creel.html), but it seems
> this information is a little outdated.
>
> What is your experience with performance of Eiffel programs in terms of
> memory footprint and execution speed?

I think the most important for this would be a runtime that allows you
to program
in a C style with explicit memory management and without GC.

I would like to see something like this. But it does not yet exist in
our solar system.

On Mon, 18 Feb 2008 12:22:29 -0800, llothar wrote:

> On 18 Feb., 19:15, Daniel Klünder <kluen...@cs.rwth-aachen.de> wrote:
>> Hi all,
>>
>> does anyone know of an embedded or real-time project out there which is
>> using Eiffel? I've heard of HP using Eiffel for their printers
>> (seehttp://archive.eiffel.com/eiffel/projects/hp/creel.html), but it
>> seems this information is a little outdated.
>>
>> What is your experience with performance of Eiffel programs in terms of
>> memory footprint and execution speed?
>
> I think the most important for this would be a runtime that allows you
> to program
> in a C style with explicit memory management and without GC.
>
> I would like to see something like this. But it does not yet exist in
> our solar system.


If you're keen to program in C style with explicit memory management,
then there are several (many!) choices available: most languages designed
before 1990 should fit the bill (but not most of the lisp family, of
course). Fortran and Forth are extreme cases: only stack and globals.
Pascal or Modula-2 might suit an Eiffeler a little better. There's C, C+
+ and Objective-C, of course. If you were really keen to manually manage
objects, it might be possible to use SmallEiffel with the "no-GC" option:
just allocate pools of objects at startup and be careful to *never* make
a new object after that. Doesn't sound like much fun, IMO.

On the other hand, there is quite a bit of embedded work going on in
systems that *do* use garbage collection. Perhaps not PIC and 8051-level
embedded, but if you can put a full Unix distribution into a $100 phone
(and many are exactly that), then a garbage collector really isn't going
to be much of a worry. Go with the dynamic memory goodness and write
good, clean code that someone will thank you for, when they have to
extend it, years later.

Cheers,

--
Andrew

On 19 Feb., 12:04, Andrew Reilly <andrew-newsp...@areilly.bpc-
users.org> wrote:

Yes maybe i'm stuck in my thinking that embedded is "small".

But if not what the hell should the question tell us. In this case any
language is as good or bad as for all programming tasks. He wrote
"embedded or real-time". So i guess the only thing open for discussion
is then real-time.

But this will result again in a comparision of the current available
runtime libraries. Do they allow multi threading, coroutines, signal
handling etc. For SmartEiffel the answer is clearley no and at least
coroutines and signal handling is also not possible with EiffelStudio.
At least this was with 5.3.

Oh yes i forgot one very serious problem with Eiffel. It compiles to C
and there is no way to tell the compiler to generate a "volatile"
specifier for variables. I guess this alone is enough to say that the
language itself will not work well with typical real-time and embedded
uses. I asked exactly this question in this newsgroup before.

On 19 Feb., 12:04, Andrew Reilly <andrew-newsp...@areilly.bpc-
users.org> wrote:

Yes maybe i'm stuck in my thinking that embedded is "small".

But if not what the hell should the question tell us. In this case any
language is as good or bad as for all programming tasks. He wrote
"embedded or real-time". So i guess the only thing open for discussion
is then real-time.

But this will result again in a comparision of the current available
runtime libraries. Do they allow multi threading, coroutines, signal
handling etc. For SmartEiffel the answer is clearley no and at least
coroutines and signal handling is also not possible with EiffelStudio.
At least this was with 5.3.

Oh yes i forgot one very serious problem with Eiffel. It compiles to C
and there is no way to tell the compiler to generate a "volatile"
specifier for variables. I guess this alone is enough to say that the
language itself will not work well with typical real-time and embedded
uses. I asked exactly this question in this newsgroup before:

http://groups.google.com/group/comp....4f17416c6c8425

> But this will result again in a comparision of the current available
> runtime libraries. Do they allow multi threading, coroutines, signal
> handling etc. For SmartEiffel the answer is clearley no and at least
> coroutines and signal handling is also not possible with EiffelStudio.
> At least this was with 5.3.

I'm not sure what is not working with EiffelStudio in the area of signal
handling as we do support signals, they are just transformed into
exceptions. And if you want to ignore a signal you have the UNIX_SIGNALS
class for that (although called UNIX it works on Windows but with a
restricted set of signals).

> Oh yes i forgot one very serious problem with Eiffel. It compiles to C
> and there is no way to tell the compiler to generate a "volatile"
> specifier for variables. I guess this alone is enough to say that the
> language itself will not work well with typical real-time and embedded
> uses. I asked exactly this question in this newsgroup before:
>
> http://groups.google.com/group/comp....4f17416c6c8425

There is no such thing in Eiffel for the good reasons that it was evil
from C to propose such a thing. Everything should have the semantic of
volatile and only when the C compiler can assure at 100% that it is ok
to not refetch data from memory can he do the optimization. That was the
idea of the register keyword in the old days because compiler needed
help to see if they didn't have to refetch but it looks like the C
standard went in the complete opposite direction.

In Eiffel, the memory model being assumed is the one that you always
fetch the data where it is. So there should not be any volatile issue.

And if you have data shared among threads, the literature will say that
you should always use synchronization routines unless you can prove it
otherwise by testing on your specific platform/C compiler.

Regards,
Manu

On 20 Feb., 00:00, "Emmanuel Stapf [ES]"
<manus_no_s...@eiffel.nospam.com> wrote:
>
> I'm not sure what is not working with EiffelStudio in the area of signal
> handling as we do support signals, they are just transformed into
> exceptions. And if you want to ignore a signal you have the UNIX_SIGNALS
> class for that (although called UNIX it works on Windows but with a
> restricted set of signals).

Okay but is it possible to write signal handlers in eiffel?

> In Eiffel, the memory model being assumed is the one that you always
> fetch the data where it is. So there should not be any volatile issue.

This is really expensive in many cases and impossible for a compiler
to figure out
so there has to be an annotation. It was not specified in Eiffel for
one very simple
reason: It was just not on the agenda.

If i see how SCOOP took people in talking about things without any
real programmers
life relevance i know why the whole multithreading is not done well
and why i had
to patch my own smalleiffel version.

llothar wrote:
> On 20 Feb., 00:00, "Emmanuel Stapf [ES]"
> <manus_no_s...@eiffel.nospam.com> wrote:
>> I'm not sure what is not working with EiffelStudio in the area of signal
>> handling as we do support signals, they are just transformed into
>> exceptions. And if you want to ignore a signal you have the UNIX_SIGNALS
>> class for that (although called UNIX it works on Windows but with a
>> restricted set of signals).
>
> Okay but is it possible to write signal handlers in eiffel?

At the moment, no because signals are mapped to exceptions. So if you
want to program your code so that once the signal processing is done you
simply continue the execution, then you need to design your Eiffel code
with the proper set of rescue clauses that will help you achieve this.

> This is really expensive in many cases and impossible for a compiler
> to figure out
> so there has to be an annotation. It was not specified in Eiffel for
> one very simple reason: It was just not on the agenda.

I'm not sure what is expensive. The default should be `volatile' and
then the optimization is to put things in register. Eiffel agenda is
that of a coherent memory model where programmers don't get gotchas, so
this is why the discussion doesn't need to take place.

> If i see how SCOOP took people in talking about things without any
> real programmers
> life relevance i know why the whole multithreading is not done well
> and why i had to patch my own smalleiffel version.

I'm not sure what SCOOP has to do with that, but EiffelStudio had a
consistent multithreading implementation since it was first introduced
in 1997. The model changed over the years but it is working great and
many applications are benefiting from it.

Manu

On 27 Feb., 01:03, "Emmanuel Stapf [ES]"
<manus_no_s...@eiffel.nospam.com> wrote:
> I'm not sure what is expensive.

The semantics of memory barriers are difficult and unfortunately not
wide understood.
I also don't understand too much about it. But if read here.

http://msdn2.microsoft.com/en-us/lib...55(VS.85).aspx

The cost of a memory barrier depends on the CPU architecture. It is
almost cost free on
current Intel i386 CPU's. It just disables the out of order execution
of the CPU.
But on PPC and SPARC there is a cost. NUMA has a high penality for
this. And the Core3
will have a NUMA Bus instead the current frontside bus.

So your solution might work now for most customers but it is not a
good decision for the
future. I see a very hard future for Eiffel if it can not come up in
the next 10
years with all the fancy multithreading features that will now come
soon. SUN's
implementation of Rock with transactional memory and lock free
algorithms is the
start of the new area. You should read "comp.programmer.threads" and
you see how
difficult low level thread programming can be.

I just feel that you want to break Einsteins Law:
"Make it as simple as possible but not simpler."
But Multithreading/Multiprocessing is not simple. Looks like you try
to explain
quantum mechanics without tensors.

Eiffel needs more here. I looked into adding OpenMP stuff into my
eiffel compiler, it's
not that difficult but if you act as language lawyer it is very
difficult to specify
the exact effect of the multithreading. Something that people are
still discussing after
ten years of SCOOP. And if you can't came up with this after 10 years
it is the best prove
that the whole concept terrible sucks (the famous exception in a
thread question).