GNU 68K vs. MRI 68K compiler
Joe Niedercorn
compiler vs. GNU 68K compiler for small embedded systems.
- Joe Niedercorn
Internet: j...@cais.com
Peter Jakubek
Well,
I have been told it is possible to configure the GNU compiler for embedded
systems, but I wouldn't use it for embedded targets unless necessary.
I know it produces excellent code, is pretty stable, is free etc.,
but in case of a problem I prefere to have someone to call up to fix it.
(Especially if you try to make money, which is likely if you write programs
for embedded systems).
I use the GNU compiler for native programming on a PC (x86) and Amiga (68k),
as long as it is for testing of algorithms, fun etc.
I use the Microtec compiler for embedded systems (68k). They have a pretty
good support and that is very important for me in case of a bug of the compiler
that can not be worked around.
Of course with the GNU compiler you get the source code and (theroretically)
you have everything necessary to fix a bug yourself - but practically that
means to understand the code, which in my opinion is not a question of a few
hours of examination.
So my conclusion is to prefere a product with support (like the Microtec
compiler), just in case you need it.
My experience with the Microtec-Compiler: it is stable, well documented,
whole library in source etc. - and: an excellent support.
Hope this helps,
Peter Jakubek
Jerry Serviss
Alex Colvin <m...@coos.dartmouth.edu> wrote:
>pj...@berlin.snafu.de (Peter Jakubek) writes:
>
>>In <41t4bc$7...@zippy.cais.net>, j...@cais.cais.com (Joe Niedercorn) writes:
>>>Does anyone have any information/experience about the Microtek 68K
>>>compiler vs. GNU 68K compiler for small embedded systems.
>
>>(Especially if you try to make money, which is likely if you write programs
>> for embedded systems).
>
>http://www.cygnus.com
>
we have used Cygnus porting, customization and support of the GNU compiler
for what is essentially an embedded system.
They do a good job
--
"Any clod can have the facts, but having opinions | Jerry Serviss
is an art." (Charles McCabe) | Motorola Inc
| ser...@cig.mot.com
Bengt Kleberg
: Does anyone have any information/experience about the Microtek 68K
: compiler vs. GNU 68K compiler for small embedded systems.
: - Joe Niedercorn
: Internet: j...@cais.com
Allow me to suggest an email to the following address. Mr Felisiak is
very knowledgable with embedded systems and has a large experience with
both gcc and mcc68k.
It is only from fear of misquote that I suggest this approach.
> Nick Felisiak ni...@tweed.demon.co.uk
> Copestone Research Ltd +44 1721 730 288
> Eddleston by Peebles, Scotland
> Networking, Unix, and Embedded Systems Consulting
Best Wishes, Bengt
-------------------Try to email: bengt....@enea.se---------------------
Disclaimer: 'If loops' are notoriously too short.
I only represent myself, not ENEA Data nor the company I work at.
Alex Colvin
>In <41t4bc$7...@zippy.cais.net>, j...@cais.cais.com (Joe Niedercorn) writes:
>>Does anyone have any information/experience about the Microtek 68K
>>compiler vs. GNU 68K compiler for small embedded systems.
>but in case of a problem I prefere to have someone to call up to fix it.
>(Especially if you try to make money, which is likely if you write programs
> for embedded systems).
You'd want to get it via Cygnus support ("free software you can afford")
http://www.cygnus.com
--
Alex Colvin
alex....@dartmouth.edu
alex_...@fostex.com
Matthew P. Downs
>In article <42115h$h...@world.celsiustech.se> b...@celsiustech.se (Bengt Kleberg) writes:
>>Joe Niedercorn (j...@cais.cais.com) wrote:
>>: Does anyone have any information/experience about the Microtek 68K
>>: compiler vs. GNU 68K compiler for small embedded systems.
>>
>>: - Joe Niedercorn
>>: Internet: j...@cais.com
>>
>>Allow me to suggest an email to the following address. Mr Felisiak is
>>very knowledgable with embedded systems and has a large experience with
>>both gcc and mcc68k.
>How could I not follow that up? :-).
>I have indeed worked with both these systems (and several other commercial
>cross-compilers). Let me first temper my remarks with the note that I
>haven't used MRI for a couple of years, so I'm talking from a historical
>perspective.
>My experiences of the MRI compiler have, to be honest, less than 100% happy.
>In several projects porting communications protocol stacks, the MRI
>compiler has produced incorrect code. Finding this, even once, extends
>the development process - every bug in the code has to be checked against
>both the source code *and* the compiled object code. Add to this the
>hassle of the abominable license server (if the supplier won't trust the
>customer, why should the customer trust the supplier?) and I'm afraid
>MRI doesn't come top of my list.
>I'm not going to claim gcc is perfect - it's a moving target, and a big
>and complex beast. However, it is used in 'industrial strength' systems -
>for instance Wind River support it as their compiler of choice for many
>platforms, and there is a wealth of experience here on the net. For
>those who want more 'committed' support, there are several organisations,
>of whom Cygnus are by far the best known, who will provide support and
>development contracts. Since the source code is available, applying any
>suggested fixes is straightforward - certainly better than shipping a binary
>over a dial-up connection :-)!
>I'm currently using gcc on a Sun platform to produce 68k code for a variety
>of targets (302, 020, 332), and on a Linux platform for an embedded PC
>application, and I don't remember the last time I hit a compiler bug on
>either target architecture. On the other hand, being able to tweak the
>compiler to plant tracing code on procedure entry/exit has saved me having
>to rent an ICE or logic analyzer to undertake some performance analysis.
>Finally, there's a mailing list for users of gcc as a cross-compiler,
>hosted by Cygnus - cros...@cygnus.com. (Subscription requests should
>be addressed to crossgcc-request, I guess). This covers cross-compiler
>configuration issues, library support, and often gets into general
>embedded systems issues, particularly for 68k platforms.
>I'm happy to answer questions which this posting may raise; if posting them
>to the group, cc to me as I tend to get behind on news.
>Nick
You should try some of the latest releases. I have been more pleased with them
than I have been with GNU. I have had more problems getting every thing for the
environment right with GNU and then still having small problems. With MCC I have
setup the environment and been running. I still have some small problems, but I
have not been 100% pleased with any complier.
I would choose Microtec over GNU for any commerical application.
Matt
Jeffrey L. Franks
|> Nick Felisiak <ni...@tweed.demon.co.uk> writes:
|>
|> >In article <42115h$h...@world.celsiustech.se> b...@celsiustech.se (Bengt Kleberg) writes:
|> >>Joe Niedercorn (j...@cais.cais.com) wrote:
|> >>: Does anyone have any information/experience about the Microtek 68K
|> >>: compiler vs. GNU 68K compiler for small embedded systems.
|> >>
|>
|> >I'm happy to answer questions which this posting may raise; if posting them
|> >to the group, cc to me as I tend to get behind on news.
|>
|> >Nick
|>
|>
|> You should try some of the latest releases. I have been more pleased with them
|> than I have been with GNU. I have had more problems getting every thing for the
|> environment right with GNU and then still having small problems. With MCC I have
|> setup the environment and been running. I still have some small problems, but I
|> have not been 100% pleased with any complier.
|>
|> I would choose Microtec over GNU for any commerical application.
|>
|> Matt
I've used both of them. I prefer GNU68k. Ours was supplied as an integrated
product however so that we did not have any support issues.
--
:---------
:Jeff Franks
: _____________________
: \___________________/______________ QC Tools -
: \ ______ / --- / a wholly owned subsidiary of
: \ |__ __| / / \ / Input/Output, Inc.
: \ | | / | O | / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: \ _| |_ / \ / / Internet : fra...@wg2.waii.com
: \ |______| / --- / Voice : (713) 964-6199
: \________/_____________/ Fax : (713) 964-6218
: /_____________/
Nick Felisiak
>Joe Niedercorn (j...@cais.cais.com) wrote:
>: Does anyone have any information/experience about the Microtek 68K
>: compiler vs. GNU 68K compiler for small embedded systems.
>
I'm happy to answer questions which this posting may raise; if posting them
to the group, cc to me as I tend to get behind on news.
Nick
--
Nick Felisiak ni...@copestone.com
toby cabot
In article <41t4bc$7...@zippy.cais.net>, <j...@cais.cais.com> writes:
>
> Does anyone have any information/experience about the Microtek 68K
> compiler vs. GNU 68K compiler for small embedded systems.
>
> - Joe Niedercorn
Joe,
I'll assume you mean Microtec Research, if so then the thing that tips
the balance to them (for us) is that they have a nice
position-independent data feature for the 68k which we use extensively.
It costs you two instructions instead of one (until you get up to the
'020) but in our case it's very useful. BTW, many commercial vendors
don't support this feature either, I had to explain to one guy how to do
it after he claimed it was impossible.
We have tried a few times (half-heartedly) to figure out how to make GCC
do this but haven't figured it out. If anyone knows how please let me
know.
Toby
Peter Jakubek
a few days ago I stated: I'd rather use the Microtec compiler, because
there is support. Unfortunately my last experience is completely different -
and I have to correct myself!
What happened?
Over a year I used the Microtec compiler without encountering any
serious problems. Whenever I had a question I called the (german) hotline
and allways found someone that could help me - immediatly, or by receiving
another call at least the next day. Once I had a problem with the compiler
(don't remember exactly what it was) that required an updated - I received
it withing a few days.
So, that is why I said Microtec offers an excellent support.
Here the story about my last expecience, that caused me to change my mind...
A few weeks ago, Microtec announced a new release of the C++ compiler, that
doesn't produce an intermediate C source. We decided to upgrade to
that release to take advantage of all the C++ features. (The previous versions
of the C++ compiler didn't compile our existing C source and it would have
been too hard to change our source that much. The hope was, it would be
easier with the new version.)
So, A few weeks ago, we received the new release of the C++ compiler (2.0C)
and by doing some tests, we found it wouldn't be too hard to change our
code, to get compiled under C++.
So we started to change our source, to get it compiled under C++ and also
started to change a few things, to take advantage of C++. The project I'm
talking about is about 200-300 thousand lines - that means it was some work
to get it done.
The first impression was pretty good and the first time we linked and loaded
our software, we all thought it was worth the trouble - now beeing able to use
C++ features in the future.
Right before we started to test the system, to validate the code, now compiled
under C++, I carefully looked over all options used to compile the system - and
discovered I forgot an option, to tell the compiler we want 'double' to be
treated as 32 bit. That option is necessary for two reasons: compatibility and
performance.
I changed the options and recompiled the whole system over night. But the next
day, when I tried to run it, it didn't work. Investigating the code, I found
the problem was caused by a wrong coding of double constants by the compiler.
But hey, that't not a big deal (I thought). We just signed (and payed for) the
support contract. The wrong coding can probalby be fixed easily!
So I called the hotline, gave a precise explanation of the bug. The same day,
I also send a fax with a small listing of a program that can be used to
reproduce the bug, including the options used to compile it. Also I explained
that we NEED a fixed compiler (there wasn't a way to workaround).
The next day I received a call by Microtec and they told me, they could
reproduce the bug, and passed it to Microtec USA, to get it fixed.
Two days later, I called the hotline again, to see if the fixed compiler is on
the way - or about to be send. Again I explained we need it fast and why...
The conversation about delivery of a fixed compiler ended like this:
(It is not exactly the words, of course we talked in german, but it is how
I remember it)
Microtec: We will fix the bug in the next release of the compiler.
Me: Yes, but when will it be?
Microtec: Well, you know, it allways takes several weeks to create a
new release.
<here I asked again and again, what exactly 'several weeks' means. I
didn't get an exact answer, but had the impression it means at least
one or two months>
Me: What does that mean? I thought, I explained we need the fix fast!
So 'several weeks' doesn't mean, we will get a fixed
compiler by the end of next week or so?
Microtec: Sorry, no - I passed it to Microtec USA, as I told you.
Me: In your advertising - and even in the support contract - 'support'
sounds different?!
Microtec: hmm.
The same day I send a fax to make clear, that this is not acceptable
- they didn't react.
I'm really upset about that behaviour, especially after telling everybody
over the net, that Microtec offers an 'excellent support'.
I'm not shure wether the people of Microtec Germany are responsible for this.
It appears to me as if they are stuck to the support they get (or not) by
Microtec USA! Obviously Mictorec Germany doesn't have access to the source
code and can not help us, even if they want - and I have got the impression
they would, if they could.
So all the work we did, hoping we might use C++ in developping our product
further, can be thrown away! (sorry Christian Massnick, and Christian
Suesskind, who worked with me to get it done).
We just can not wait 'several weeks', before getting the next release of our
software done.
To OUR customers 'support' really has a meaning.
To make it clear again: I'm not complaining, that there is a bug in the latest
release of the Microtec compiler - it is practically impossible to avoid bugs
in software completely, that's why I think support is important.
I'm complaining about their (Microtec) understanding of the word 'support'!
Conclusion: I still believe it is important to get support for a tool like
a compiler - but I'm not expecting to get it by Microtec!
I'm starting to consider the GNU compiler in the future - especially since
I've been told, it is no longer such a pain to configure it for embedded
systems. Also, I have been told, there are companies that offer support.
(Even if the support fails, I will have the source code of the compiler,
and thereby have at least a chance, to fix the bug myself.)
Sorry, that I wasted bandwith,
Peter Jakubek,
pj...@berlin.snafu.de,
engineer at LaserAnimation Sollinger GmbH Berlin
PS: 'Microtec' = 'Microtec Germany' refers to:
Microtec Research GmbH
Haidgraben 1c
D-85521 Ottobrunn/Munich
Germany
I'm not shure what 'Microtec USA' refers to.
Frey Waid
>The conversation about delivery of a fixed compiler ended like this:
>(It is not exactly the words, of course we talked in german, but it is how
> I remember it)
> Microtec: We will fix the bug in the next release of the compiler.
> Me: Yes, but when will it be?
> Microtec: Well, you know, it allways takes several weeks to create a
> new release.
> <here I asked again and again, what exactly 'several weeks' means. I
> didn't get an exact answer, but had the impression it means at least
> one or two months>
> Me: What does that mean? I thought, I explained we need the fix fast!
> So 'several weeks' doesn't mean, we will get a fixed
> compiler by the end of next week or so?
> Microtec: Sorry, no - I passed it to Microtec USA, as I told you.
> Me: In your advertising - and even in the support contract - 'support'
> sounds different?!
> Microtec: hmm.
This has been my experience with Microtec. It doesn't seem to make
much sense to offer support where the only answer is "we'll fix it in
our next release."
>Conclusion: I still believe it is important to get support for a tool like
>a compiler - but I'm not expecting to get it by Microtec!
>I'm starting to consider the GNU compiler in the future - especially since
>I've been told, it is no longer such a pain to configure it for embedded
>systems. Also, I have been told, there are companies that offer support.
>(Even if the support fails, I will have the source code of the compiler,
> and thereby have at least a chance, to fix the bug myself.)
If your hardware is a 68k, try either Diab's or SDS's C++
cross-compilers. I currently use Diab and find their support pretty
good.
Frey
Stephen Williams
In article <41t4bc$7...@zippy.cais.net> j...@cais.cais.com (Joe Niedercorn) writes:
Joe> Does anyone have any information/experience about the
Joe> Microtek 68K compiler vs. GNU 68K compiler for small embedded
Joe> systems.
(Disclaimer: I only installed the MRI compiler, and promptly
uninstalled it when the customer decided they couldn't afford to leave
me a license. Therefore, this is not a comparison of GNU and MRI
specifically.)
I use gcc 2.7 configured to generate m68xxx code, along with
binutils-2.5.2, which includes the assembler and linker. I've also
used it on the SPARC (Sunos4 and Slowaris2) and ix86 (FreeBSD, Linux
and embedded.) There is just no end to its breadth and
applicability. This is an enourmous win for me.
Having a C++ compiler at that price (free) is amazing, and it works
quite well. It generates perfectly acceptable code. I've yet to run
into a bug. It is actually *easier* to install GCC et. al. then the
MRI compiler. Clearly, Cygnus has lots of embedded systems programmers
as customers. I'm impressed.
In the past I've used commercial compilers for other non-embedded
environments, and the GNU compiler as well. I have always lobbied, and
got, the GNU compiler because of the price, quality, and lack of
license manager.
The license manager is suprisingly expensive for me, as I work at
home, but sometimes (in a rare while) take my work to the office. It
has also caused many headaches when many people are working on larger
projects (even when there are enough licenses) or a license manager
has trouble (which is pretty often.)
If you want support, I suggest Cygnus (http://www.cygnus.com) I
personally have never felt the need for support, yet I've used the
GNU compiler in multi-million dollar projects. However, I'm a fairly
sophisticated programmer--the more casual user may get value out of
having a pretty box on the shelf and a phone number in the rolodex.
You can also get help configuring and installing the compiler from
gnu.gcc.help. (I can send you some simple instructions for m68k as
well, if you would like. I work on a sparc.)
--
Steve Williams
st...@icarus.com
st...@picturel.com
Kurt Guntheroth
>Hmm,
>
>a few days ago I stated: I'd rather use the Microtec compiler, because
>there is support. Unfortunately my last experience is completely different -
>and I have to correct myself!
>
>What happened?
>
>under C++, I carefully looked over all options used to compile the system - and
>discovered I forgot an option, to tell the compiler we want 'double' to be
>treated as 32 bit. That option is necessary for two reasons: compatibility and
>performance.
>I changed the options and recompiled the whole system over night. But the next
>day, when I tried to run it, it didn't work. Investigating the code, I found
>the problem was caused by a wrong coding of double constants by the compiler.
>
>that we NEED a fixed compiler (there wasn't a way to workaround).
>The next day I received a call by Microtec and they told me, they could
>reproduce the bug, and passed it to Microtec USA, to get it fixed.
1. Have you tried the simple expedient of adding to one of the include
files the line
# define double float
This might temporarily fix the problem by turning all doubles into
floats.
2. Expecting 2 day turnaround for a bug in something as big as a C++
compiler seems unreasonable to me. Remember that rapid turnaround
and thorough testing are incompatible. If they are getting a stable
release out "every few weeks" they're doing pretty good. The time they
spend is needed to insure the change is right. You would howl just as
loudly if they rushed you a patch that broke something else, so they are
doing you the favor of being professionals and testing their work.
It's not their fault you waited to the last minute to test.
One thing about the GNU compiler, you get the sources. You can then
implement your own bug fixes if they're as simple as you think, and
if you don't want to carefully test the fix, you can put the patched
compiler right into production. You get th manage the risk for yourself.
Stephen Worthington
>pj...@berlin.snafu.de (Peter Jakubek) wrote:
>
>>I'm starting to consider the GNU compiler in the future - especially since
>>I've been told, it is no longer such a pain to configure it for embedded
>>systems. Also, I have been told, there are companies that offer support.
>>(Even if the support fails, I will have the source code of the compiler,
>> and thereby have at least a chance, to fix the bug myself.)
>
>cross-compilers. I currently use Diab and find their support pretty
>good.
SDS's support is *excellent*. Very rapid turnaround of queries, and I
have had a bug fix withing 24 hours whenever I said I needed one
urgently. And *very* few bugs (usually only in very new features).
--
Stephen Worthington Telephone: +64-4-569-6764 (home)
Digi-Tech Communications Ltd +64-4-389-8909 (work)
ste...@digitech.co.nz (work) Fax: +64-4-389-9901 (work)
ste...@inisant.actrix.gen.nz (home)
Len Picone
>SDS's support is *excellent*. Very rapid turnaround of queries, and I
>have had a bug fix withing 24 hours whenever I said I needed one
>urgently. And *very* few bugs (usually only in very new features).
>
>
in response time. Unfortunately, they misled us about incorporating some of the new
language features. When we purchased their C++ compiler, we were told that template
support was coming. Months later we find out that since nobody is demanding it,
that they are not working on it. I'm concerned about their long term outlook for
C++ support, especially concerning future language changes. We are currently
evaluating Diab's compiler. No conclusion yet.
Len Picone
l...@rfc.comm.harris.com
Disclaimer: All opinions and ideas are my own, not my employer's.
Frey Waid
>ste...@atlantis.actrix.gen.nz (Stephen Worthington) wrote:
>We are currently using SDS's 68K C++ compiler and their support has been very good
>in response time. Unfortunately, they misled us about incorporating some of the new
>language features. When we purchased their C++ compiler, we were told that template
>support was coming. Months later we find out that since nobody is demanding it,
>that they are not working on it. I'm concerned about their long term outlook for
>C++ support, especially concerning future language changes. We are currently
>evaluating Diab's compiler. No conclusion yet.
Templates were main the reason I went with the Diab compiler. I've
had good support with Diab even if sometimes they send me incomplete
packages. Usually, they'll post fixes, revisions, upgrades, and what
not on their ftp site within a couple hours of my request. One
problem though: they're located in the west coast -- a problem for us
easterners. That means no one's in the office until 11:30 my time.
Frey Waid
Mike Albaugh
: je...@imada.ou.dk (Hans Peder Jepsen) writes:
: >I have a question though: How do one produce target-files in
ieee-695-format
: >(filename.x - a "small" x, not a capital X). We have to use a ieee-695-file
for
: >our debugger and emulator.
: Real Soon Now the GNU tools will fully support iee695, but for now it's
: still a work in progress. Some emulators can use srecords, and GDB can load
: a COFF file, which works much better than ieee695.
Keep in mind, that this "Real Soon Now" has been the answer for
at least four years. YMMV, but that does not seem like reality to me.
Also, the whole idea that COFF is adequate for embedded development is
a bitter joke on folks who were used to post-1965 linker technology before
moving to the GNU toolchain (like, me :-( )
I have been using the GNU compiler since 1.18 and find it to be
as wonderful as you have heard, but I have also been using the rest of
the toolchain (gas, gld, gdb) for about two years and "Suck rocks" is
the most polite thing I can say. 'Nuff said?
Sorry to be rude to folks who have done such (otherwise) good
work, but perhaps such overt confrontation will produce results where
mere pleas (and money) have so far failed.
Mike
| Mike Albaugh (alb...@agames.com) Time Warner Interactive
| (The entertainment company formerly known as Atari Games (_NOT_ Tramiel's))
| 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709
| The opinions expressed are my own (Boy, are they ever)