Best compiler for embedded development

[lee]

Folks,

I have a few questions because I've been asked to investigate eiffel
for use in some embedded development. As you may know, the embedded
world is characterized by the following:

1. Variety of chip architectures
2. Most popular OS is linux and the most popular "brand" of linux is
"roll your own"
3. Efficient memory utilization is important
4. Many chips are multi-core, which means parallelization is becoming
important.
5. For our segement, speed is also very important.

Given these characteristics, I would like to hear opinions from
eiffelists about the comparitive strengths of Smarteiffel and
EiffelStudio. I like the development enviroment of EiffelStudio (with
its case tool and integrated debugger). However, I have read about the
reputation of Smarteiffel with regards to speed and efficiency of the
executable.

As an aside, I wanted to know about the difficulty of porting eiffel to
a new hardware platform. From what I have read, I understood that if
there is a c compiler available for that hardware, and the eiffel
compiler supports the operating system on that hardware, then there
should not be a problem with seamless porting. Is that true?

Thanks in advance for any help.

Lee

[Roger Browne]

On Mon, 2006-01-02 at 12:11 -0800, lee wrote:

> As an aside, I wanted to know about the difficulty of porting eiffel to
> a new hardware platform.

Victor Putz ported SmartEiffel to the Palm PDA
http://eiffelzone.com/esd/epalm/index.html
The "Documentation" link is not working today, but I seem to recall that
Victor describes the issues he encountered and how he resolved or worked
around them.

Regards,
Roger Browne

[llothar]

Well if Boehms GC is working on your machine or you are able to port it
to the chip, and gcc 4.0 runs on this system. I have another option
for you.

I use a patched version of SmallEiffel for my inhouse development.
It has all of the features, except (3) as the memory footprint might be
high.
Unfortunately no eiffel compiler works without GC at the moment.

(4) is not possible with SmartEiffel, and the team is unwilling to see
the importance of multithreaded programming.

[lee]

Thanks for the information. I did look around to see if I could find
the files, but no such luck. Actually, it might not matter, because I
consider ePalm to be an instance of porting to both a new OS and new
hardware. If you are porting to a new OS, then I can see where the
eiffel compiler would need to be modified (e.g., to map to the specific
system calls, etc.).

I was wondering more about the case where you are porting to a
supported OS, but on a new chip.

[lee]

llothar wrote:
> >
> (4) is not possible with SmartEiffel, and the team is unwilling to see
> the importance of multithreaded programming.

Does that mean you would choose SmartEiffel over EiffelStudio given the
characteristics I was looking at (except for 4)? As for 4, I
understood that the SmartEiffel team refused to implement
multi-threading, and while I do not know their reasons, I am not a fan
of multi-threading.

Basically, I have consulted for many large companies with teams of
talented (I assume) developers. To increase throughput for large
e-commerce systems, they invariably turn to multi-threading. And they
invariably have many problems, regardless of the tools/language. My
analysis of these issues leads me to believe that threading is so
difficult because it is hard to determine the state of a complex
program. There are usually deadlock issues as well as correctness
problems Therefore, I am more partial to (a) exploring efficient
scheduling of processes/jobs within an app (i.e., a single threaded
process) and then exploiting parallelization by (b) having multiple
instances of an application.

The big missing factor is how to simply assign an app to a particular
processor and to change that assignment dynamically. That's why I am
interested in SCOOP.

Lee

[llothar]

SmartEiffel does not use system calls, its generated code is pure ANSI
C.

[llothar]

Well you don't need to be fan of multi-threading. Simply look at what
happens in the CPU world at the moment. CPU speed is almost the same as
2 years ago so we see a dead end here - there are physical borders. And
you can get a dual core CPU in each supermarket and a 32 threaded CPU
chip from SUN.

The process modell does only work well for a few kinds of tasks. For
others you simply need shared memory structures, otherwise the IPC eats
up all the speed.

I agree that at the beginning the multi-threading is a magnitude more
difficult and you need very good skills and experience to design such a
system. But i don't see any alternative. Over christmas i resurrected
an old Occam programming book from 1986. It was interesting to read
that 20 year old stuff. Multithreaded sorting algorithm etc.

[Roger Browne]

lee wrote:
> I was wondering more about the case where you are porting to a
> supported OS, but on a new chip.

For SmartEiffel this should require only that the new chip has a
suitable Ansi C compiler. If it takes more than that, I think the
SmartEiffel team would regard it as a bug.

lee (asking llothar):

> Does that mean you would choose SmartEiffel over EiffelStudio

They are very different solutions. SmartEiffel is a lean open source
command-line compiler that you can port yourself. EiffelStudio is a
richly-featured proprietary compiler, but as you don't get the source
code to the runtime you will have to get the vendor to port it (which
they will be keen to do if it is economically viable for them).

Regards,
Roger Browne

[lee]

llothar wrote:
> > I agree that at the beginning the multi-threading is a magnitude more
> difficult and you need very good skills and experience to design such a
> system. But i don't see any alternative. Over christmas i resurrected
> an old Occam programming book from 1986. It was interesting to read
> that 20 year old stuff. Multithreaded sorting algorithm etc.

You have a good point. There are some tasks that are good for
multi-threading. In some ways, my negative view of multi-threading is
a result of my negative view of development practices. When I studied
computer science 20 years ago, we were required to study algorithms.
At the time, I was bored to death to learn about notation that looked
liked - O(n), etc. I wanted to program a computer that could think!

But, as I entered the "real" world, I noticed that spending time on
algorithm development (before actually writing code) could result in
orders of magnitude improvement. I do not see developers spending much
time on algorithms nowadays. So, instead of trying to create
algorithms that limit the number of disk accesses (as an example),
developers write code that is inefficient (but at least it is written
quickly, I guess). Then, when they need to address performance, they
turn to multi-threading. If they had created better algorithms in the
first place, then they might have eliminated the performance bottleneck
in the first place.

Lee