Bye bye Keil 166 and 8051 (??) - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Bye bye Keil 166 and 8051 (??)
Quoted text here. Click to load it

Certainly not.
The fact that it is open source makes matter worse.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Bye bye Keil 166 and 8051 (??)


Quoted text here. Click to load it

I think Chris was bitten by an open-source dog when he was still a babe
in arms.


Re: Bye bye Keil 166 and 8051 (??)
Quoted text here. Click to load it
No.  I have seen many people complain of bugs in compilers when in fact
is was their lack of understanding of the language was the problem.
Probably 9 out of 10 cases.

Now if these people can fix the "bugs" in open source compilers to what
they thing it should do you have a very poor compiler the user thing si
perfect.

Especially if the can modify the test suite to take into account their
"fix"

I have been informed that the Gnu test suite is not a test suite as such
but simply a confidence check that the build has gone OK.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Bye bye Keil 166 and 8051 (??)
Quoted text here. Click to load it

The people that actually fix open-source programs as complicated as
compilers are not in these 9 out of 10 cases.  Have you the slightest
idea of what is involved in getting a patch into the gcc tree?  To put
it mildly, you won't get your patch accepted if you are in that 9 of 10
group.  Theoretically, of course, you could download the source, make
the change to your own local copy to fix the "bug", and re-compile.  In
practice, that doesn't happen - people only patch and re-compile if they
are very capable, and know the issue is a bug and not a misunderstanding
(and in almost all cases, after discussing it with other experts on
mailing lists).  But if you *are* in that category of expertise, and
find a *real* bug, then begin open source, you can do exactly such a
patch and re-compile.  That way you get the fix immediately, rather than
waiting for the next compiler release, as is the normal case for both
open and closed source tools.

Quoted text here. Click to load it

That may well be the case.  If I want to be sure that a particular gcc
version passes a particular "standard" conformance test, then I can run
that test myself.  If I want to be sure that a particular commercial
compiler passes such a test, then I *also* have to run the test myself.
  I suppose there might be a middle-ground, where I want a compiler that
I am reasonably confident passes the test, in which case I could take
the commercial vendor's word for it.  Maybe that suits if you have the
attitude that you don't mind if your products work, as long as there is
someone else to blame and sue.

Re: Bye bye Keil 166 and 8051 (??)
snipped-for-privacy@gmail.com says...
Quoted text here. Click to load it

I think he's just a troll.  I haven't actually seen him post any useful
information, ever.  He seems quick to jump on the "GNU sux" or "Open
Source Sux" whenever possible, but doesn't really provide any valuable
insight.

Case in point:  Awhile back someone asked about ARM dev tools and the
post goes unanswered for a few days.  I follow up and mentioned that the
GNU ARM tools are free and an option for the original poster (I didn't
claim that the GNU toolset produces the most optimal code, but I did
state it was free).  Chris Hills then jumps in and tromps all over GNU.  
I didn't recall seeing him post anything before the mention of GNU...

Everyone agrees that GNU tools have their + and -s.  No one is claiming
GNU is perfect and/or couldn't use work in a lot of areas.  But for many
projects they have the right mix of price and features, caveats
included.

Regarding Chris Hills,  I bet a good number of the websites visits use
Apache and a BSD or a Linux there.  Some part of everything we do
probably touches an OpenSource or GNU influenced product or project
through means we may not think about.

So Chris Hills, stop the bullshit GNU trollings and post useful
information or go away.

H.



Re: Bye bye Keil 166 and 8051 (??)

Quoted text here. Click to load it

My experience is exactly the opposite.  

When I found bugs in commercial toolchains, I was basically
ignored.  When I needed additional features in commerical
toolchains, I was completely ignored.

When I found a very obscure bug in the ARM backend for gas, it
was fixed within 2 hours of reporting.  When I needed
additional features in the gnu loader, I just spent a couple
hours and added them.

--
Grant Edwards                   grante             Yow!  I had a lease on an
                                  at               OEDIPUS COMPLEX back in
We've slightly trimmed the long signature. Click to see the full one.
Re: Bye bye Keil 166 and 8051 (??)
Quoted text here. Click to load it

I think you'll find that there is well written open source software, and
badly written open source software - and that exactly the same applies
to closed source software.  Some open source software is written as
hacked together code and release "as is", and will often be poorly
coded.  Other open source code is written with pride, knowing that
others will read the code and judge the programmer by it, and is
therefore good code.  Similarly, some closed source code has careful
reviews or is written as a team, forcing structure and well written
code, while other closed source is hacked together under time pressure
and looks terrible.

Quoted text here. Click to load it
 > You do get what you pay for it's just that sometimes the people that
 > make
 > the decisions are too poorly educated to understand the real costs of
 > those decisions.
 >

That's certainly true - but there is no specific reason to assume that
an open source compiler is necessarily worse than a closed source one.
Some of the very top end compilers for some targets are noticably better
than other compilers - but there are plenty of poor quality compilers
available for some targets.  Note that I'm talking mainly about
generated code quality here - run-time speed and code size.  There are
many other factors to consider when looking for the "best" compiler for
a particular job.

Consider, for example, some compilers for the AVR (since I know these
tools, while I have not used the 8051).  According to reputation, IAR's
compiler produces the very best code, but the compiler is expensive.
ImageCraft's compiler is cheap, but has significantly poorer code.
avr-gcc is open source, and produces code that is (as far as I have
seen) never worse than ImageCraft's, and often a lot better.  It's been
a while since I have compared IAR's code generator with gcc's - it will
be interesting to see which is better with the latest gcc 4.1, but I
would certainly not assume IAR's compiler is as much ahead as the
difference in price would indicate.

Or look at high-end x86 processors.  These days, Intel's own compiler
generally wins most benchmarks - but gcc beats it for some code, and is
undoubtable closing the gap.  Or consider the Microblaize (from Xilinx)
and Nios II (from Altera).  These are two companies with a great deal of
resources, and a great deal of expertise in large closed-source
development environments.  But when looking for a compiler and IDE for
their soft processor cores, both chose to use open-source Eclipse as the
IDE, and open-source gcc as the compiler.  They chose gcc because they
felt that was the best route to getting a high-end compiler for the
processors.

I use different compilers for different purposes and different targets.
  Some compilers are closed-source, although most of my work these days
uses gcc.  When recommending toolkits to others (customers, colleagues
or others), I will sometimes recommend gcc ports, sometimes commercial
closed source tools, and sometimes commercial packings of gcc.
Personally, I don't see the choice of software as a religious issue,
though I do see why some people are fanatical about only using
open-source tools.  There are good reasons for that - depending on your
priorities, they can be the most important reasons.  But I fail
completely to understand people who are fanatically anti-open-source.
Arguing that a particular closed-source commercial tool is better than a
particular open-source tool for good, solid, practical reasons is fine -
arguing that it must of necessity be better simply because it is
commercial is ludicrous.

Regards,

David


Quoted text here. Click to load it

Re: Bye bye Keil 166 and 8051 (??)

Quoted text here. Click to load it

sdcc is a different compiler. It's not bad, and it's not good yet, but
it does do a whole host of 8-bitters.

Plus, you can add your own peephole optimisations without recompiling
the compiler, which has some ... interesting ... possibilities.

cheers, Rich.

--
rich walker         |  Shadow Robot Company | snipped-for-privacy@shadow.org.uk
technical director     251 Liverpool Road   |
We've slightly trimmed the long signature. Click to see the full one.
Re: Bye bye Keil 166 and 8051 (??)


Bo wrote On 11/04/05 04:58,:
Quoted text here. Click to load it

Different code base. GCC is pretty much biased towards "address equals data"
processors, that is, processors that can keep an address or data in any register,
and don't need to (say) use two registers together to form an address.

That fit the archtecture that GCC was going for. Other projects are there to
cover
the low end.


Re: Bye bye Keil 166 and 8051 (??)


Charlie wrote On 11/02/05 16:26,:
Quoted text here. Click to load it

You are correct. Its not good.

Lets face it, GCC and other freeware offerings have beat the compiler
industry down to a shadow of its former self. As with any such dying
business, the independents are simply deciding that it is not profitable
to remain independent. The CPU makers are willing to subsidize compiler
writing in a captive division, but not independent makers.

This is actually fine. These are market forces. These captured companies
divest themselves of CPU support other than their new parents quite
quickly. Metrowerks actually dropped non-PowerPC support before being
bought by Freescale, perhaps to make themselves more attractive to
Freescale.

Judging by the track record, Keil will drop non-arm support sooner
or later, my bet is sooner. To paraphrase Bruce Springsteen, these
compiler companies are going, boys, and they ain't coming back.

By the way, this happened to our company's processors a long time
ago, the Sparc. Today there is virtually only our own compiler and
GCC.


Re: Bye bye Keil 166 and 8051 (??)
Quoted text here. Click to load it


So where to we go for quality compilers?
Gcc ain't it.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Bye bye Keil 166 and 8051 (??)
Chris Hills wrote On 11/03/05 13:01,:
Quoted text here. Click to load it

Same place you go for quality operating systems and quality
word processors :-) :-)

Seriously. Its hard to beat free. People made a choice, and it seems
to be that the majority want "free", and don't care about quality.

Compilers are not easy to create. Its easy to create easy compilers,
which tends to make novices believe that compilers are a non-issue.
But making a first class compiler used to be equivalent to making
a moon rocket. Now, the only ones who really have the incentive to
invest this kind of time and money are the CPU makers themselves.

If I had to guess, I would say the future is that you will pick a
CPU by the quality of the tools the vendor provides for it, which
is pretty much what I suspect ARM, Freescale and others had in mind
when they bought those companies.

Our company (sun) is a good example. We make first class compilers.
Not super shiny and neat IDEs, but our compilers wring the last %1
of performance from the Sparc CPU. Some groups here at sun use the
GCC compiler anyways, just because they prefer to be %100 compatible
with what everyone else is using. However, GCC is never going to
achieve explotation of all the features of the Sparc CPU that our
own compiler group is capable of. There's no way GCC could. Our
compiler group gets the silicon when it is still warm from the fab.
They even have a say in what features the next Sparc will get.


Re: Bye bye Keil 166 and 8051 (??)
Hello Scott,

Quoted text here. Click to load it

Exactly. In my experience tool quality and tool cost has been a major
factor in deciding which product gets designed in. There is a reason why
  TI lands so many design-ins with their DSP. Their tool set isn't free
but reasonably priced. An engineer who wants (and needs) a tool set has
an easier time walking into his boss' office with that cap ex request if
the number at the bottom of it isn't in the high four digits.

Regards, Joerg

http://www.analogconsultants.com

Re: Bye bye Keil 166 and 8051 (??)
Quoted text here. Click to load it

Unfortunately true.


Yes. BUT they only tend to put as much effort in as needed to get it
working to sell chips.

Quoted text here. Click to load it

Possibly


They have a good reputation

Quoted text here. Click to load it

Exactly. Also the technology in GCC is way behind good commercial
compilers of may architectures. There is no "one size fits all"


Quoted text here. Click to load it

Well make the fab "open source " :-)



--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Bye bye Keil 166 and 8051 (??)


Quoted text here. Click to load it


I do wish people would not use the term 'technology' in relation to
software. LCD is a technology, semi-conductors are a technology but
tweaking a bit of software isn't.

Ian

Re: Bye bye Keil 166 and 8051 (??)

Quoted text here. Click to load it

Tweaking might be used to describe improving performance of a program by
changing a table of 16 bit words to 32 bit words or moving a loop control
variable to a register for faster execution but no way can you even
remotely suggest that the Sun compiler is merely a "tweak" of the GCC
compiler. Such a suggestion shows that you only have a superficial
understanding of software.


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use



.



Re: Bye bye Keil 166 and 8051 (??)
Sergio Masci wrote On 11/04/05 07:26,:
Quoted text here. Click to load it

My understanding is (which could be completely wrong), that Sun's
internal compiler shares no code at all with GCC.

Usual warning: I don't speak for Sun, the state of California,
the USA, the world, rational people, animals, trees, sentient beings,
dead people, or often, even myself.


Re: Bye bye Keil 166 and 8051 (??)

Quoted text here. Click to load it

On the contrary I was not suggesting there are not large differences between
different compilers, only that the differences are NOT attributable to
technology.

Ian

Re: Bye bye Keil 166 and 8051 (??)
Chris Hills wrote On 11/04/05 03:34,:

Quoted text here. Click to load it

You may be right for small chips. I don't recall being impressed by
the compiled output for 8 and 16 bit low end processors by commonly
available tools. I have been in high end cpus for 15 years now, and
we live and die by compiler efficiency. For example, vectorizing compilers
are mandatory here.

Perhaps what that means is that the high end superscalar processors
are going to take over most embedded apps, I don't know. ARM is
superscalar, no ?


Quoted text here. Click to load it

GCC for the AMD 64 bit series came from AMD themselves. I used the
compiler for a short while. I don't know if it vectorizes or performs
other "heroic" measures, but I'm betting AMD put a lot of work into
it.

Quoted text here. Click to load it

Actually, Sun is in fact open sourcing just about everything that
is not nailed down :-)


Re: Bye bye Keil 166 and 8051 (??)
"Seriously. Its hard to beat free. People made a choice, and it seems
to be that the majority want "free", and don't care about quality. "

Its more risk reduction, if you have two options, pay $$$ and get a
compiler that may or may not  fulfill your needs, or pay nothing and
get a compiler that may or may not fulfill your needs, option 2 has
less risk.


Site Timeline