| View previous topic :: View next topic |
| Author |
Message |
CBFalconer
Guest
|
 Posted: Thu Nov 20, 2008 5:59 am Post subject: Re: ARM IDE |
 |
|
Chris H wrote:
| Quote: | David Brown <david.brown@hesbynett.removethisbit.no> writes:
.... snip ...
Different system libraries might give different results in odd
cases). Do you test them all?
No. You are thinking GCC again. The compilers we test are supplied
with a single standard library. We test that. However it does
raise the point that will the GCC you have multiple libraries for
many sources. This makes it even more difficult to test GCC.
What about less usual circumstances, like running the windows
binary under Wine, or using some sort of virtualisation software?
We do not test it under those hosts. We state a specific host OS.
Emulations and virtual systems are up to you and you would need
to test on those systems for higher SIL.
|
How do you compensate for variations in parameter passing, calling
conventions, etc. in various libraries? Do you mean you have the
common library source, and compile it under each system?
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section. |
|
| |
|
 Back to top |
Chris H
Guest
|
| Posted: Thu Nov 20, 2008 9:07 am Post subject: Re: ARM IDE |
|
|
In message <4924A869.E944F495@yahoo.com>, CBFalconer
<cbfalconer@yahoo.com> writes
| Quote: | Chris H wrote:
David Brown <david.brown@hesbynett.removethisbit.no> writes:
... snip ...
Different system libraries might give different results in odd
cases). Do you test them all?
No. You are thinking GCC again. The compilers we test are supplied
with a single standard library. We test that. However it does
raise the point that will the GCC you have multiple libraries for
many sources. This makes it even more difficult to test GCC.
What about less usual circumstances, like running the windows
binary under Wine, or using some sort of virtualisation software?
We do not test it under those hosts. We state a specific host OS.
Emulations and virtual systems are up to you and you would need
to test on those systems for higher SIL.
How do you compensate for variations in parameter passing, calling
conventions, etc. in various libraries? Do you mean you have the
common library source, and compile it under each system?
|
We don't compile the library or the compiler. We don't start with the
source.
We test the library supplied with the compiler. We test on windows XP,
this is the host system for these compilers. They only run on windows.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |
|
| |
|
| Back to top |
Chris H
Guest
|
| Posted: Thu Nov 20, 2008 9:07 am Post subject: Re: ARM IDE |
|
|
In message <gg2134.lc.1@stefan.msgid.phost.de>, Stefan Reuther
<stefan.news@arcor.de> writes
| Quote: | Chris H wrote:
In message <gg1o0s.to.1@stefan.msgid.phost.de>, Stefan Reuther
Chris H wrote:
Quite so I can directly get in touch with all the developers and project
managers for any of the compilers I sell. Then again I have NDAs with
them as a distributor. So far I have not had any legitimate question
from a user that we have not been able to answer.
Well, you *think* you've answered their questions satisfactorily. Maybe
they just gave up trying to explain the problem.
No.
How do you know?
Multi-level support has its disadvantages when you want to go into deep
details. Like, you want to know whether __mulli3 has been designed with
CPU erratum #1009823 and application note #512 in mind, and whether you
can safely call it from inline assembly (completely made-up example). If
all you have is a first-level support contact, you'll have a hard time
trying to explain them what you want.
Why?
Granted, developer support is a *lot* more helpful than phone company
support,
|
What "phone company"?
| Quote: | but I have already got back bug reports for formal reasons
without anyone having looked at the problem. One that I remember is that
a filesystem library was unmarshalling stuff using 'char', not 'unsigned
char'
|
This is a problem I mentioned before there are three types of Char. the
sign of plain char is implementation defined. The standard library uses
plain char quite a bit
| Quote: | . Everyone sees that this is wrong by looking at the code; I sent
file name and line number. The answer I got back was "please send a
self-contained test case including an image of the failing file system".
Had I been talking to a developer familiar with the code, not a support
guy, that would probably have been fixed that in a second.
|
Absolute bollax. When talking to the internal support team or the
developer the first thing they ask for is "please send a
self-contained test case including an image of the failing file system".
They want to see an example because a lot of users do not understand the
compiler, the language or what is actually happening.
Statistically I have found it worse amongst those who say "If I had the
source I could fix it" which is why I am very unconvinced when people
say having the course of a compiler is useful
The other thing is the disti and the compiler support team may have seen
this problem many times before.... and know the solution. It is not
always (or indeed often) a compiler bug.
As for talking to "the developer" the support teams are often the same
as the developer and the rotate tasks and have a spell on the support
desk. In other places the support team is far better at handling
support problems than the developers. It is a different sort of game.
The support team are usually qualified and experienced engineers with
quite often far more experience than the people who call in. Especially
when it comes to the language and compilers.
As for "it would have been fixed in a second" what is not true. You can
just change something in a compiler. You need to look very carefully at
what else it effects and do full regression tests (for the build) and
full tests (Plum hall, maths, language extensions, corner cases etc etc
but only AFTER you have looked to see if you need to add new tests. And
done all the documentation
Some compilers where you have the source and can "fix things in a
second" are a complete bag of nails and the source is a complete
nightmare.
Like many you see the problem and the solution far too simplistically.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |
|
| |
|
| Back to top |
Stefan Reuther
Guest
|
| Posted: Thu Nov 20, 2008 5:20 pm Post subject: Re: ARM IDE |
|
|
Hi there,
Chris H wrote:
| Quote: | In message <gg2134.lc.1@stefan.msgid.phost.de>, Stefan Reuther
Granted, developer support is a *lot* more helpful than phone company
support,
What "phone company"?
but I have already got back bug reports for formal reasons
without anyone having looked at the problem. One that I remember is that
a filesystem library was unmarshalling stuff using 'char', not 'unsigned
char'
This is a problem I mentioned before there are three types of Char. the
sign of plain char is implementation defined. The standard library uses
plain char quite a bit
. Everyone sees that this is wrong by looking at the code; I sent
file name and line number. The answer I got back was "please send a
self-contained test case including an image of the failing file system".
Had I been talking to a developer familiar with the code, not a support
guy, that would probably have been fixed that in a second.
Absolute bollax. When talking to the internal support team or the
developer the first thing they ask for is "please send a
self-contained test case including an image of the failing file system".
They want to see an example because a lot of users do not understand the
compiler, the language or what is actually happening.
|
You have just proven my point. First-level support assumes the user is
too stupid to use the product, and users with a clue have a hard time to
convince them that they actually know what they're talking about.
In this particular case, the problem was in CD multisession handling,
thus "sending an image" would have meant to burn a CD and shipping it
over the ocean, along with our hardware because the reference hardware
has no CD drive. Expensive in time and money.
| Quote: | As for "it would have been fixed in a second" what is not true. You can
just change something in a compiler. You need to look very carefully at
what else it effects and do full regression tests (for the build) and
full tests (Plum hall, maths, language extensions, corner cases etc etc
but only AFTER you have looked to see if you need to add new tests. And
done all the documentation
|
The problematic code was about this:
char buffer[4];
fetch_buffer_somewhere(buffer);
address = buffer[0] + (buffer[1] <<  + (buffer[2] << 16)
+ (buffer[4] << 24);
I cannot imagine any situation where this is "more right" than
unsigned char buffer[4];
but I can imagine many situations where it is wrong. I would assume that
developers worth their money agree with me.
| Quote: | Like many you see the problem and the solution far too simplistically.
|
Yeah right, I don't have a clue, I know.
Stefan |
|
| |
|
| Back to top |
Chris H
Guest
|
| Posted: Thu Nov 20, 2008 6:57 pm Post subject: Re: ARM IDE |
|
|
In message <gg3klj.l0.1@stefan.msgid.phost.de>, Stefan Reuther
<stefan.news@arcor.de> writes
| Quote: | Hi there,
Chris H wrote:
In message <gg2134.lc.1@stefan.msgid.phost.de>, Stefan Reuther
Granted, developer support is a *lot* more helpful than phone company
support,
What "phone company"?
but I have already got back bug reports for formal reasons
without anyone having looked at the problem. One that I remember is that
a filesystem library was unmarshalling stuff using 'char', not 'unsigned
char'
This is a problem I mentioned before there are three types of Char. the
sign of plain char is implementation defined. The standard library uses
plain char quite a bit
. Everyone sees that this is wrong by looking at the code; I sent
file name and line number. The answer I got back was "please send a
self-contained test case including an image of the failing file system".
Had I been talking to a developer familiar with the code, not a support
guy, that would probably have been fixed that in a second.
Absolute bollax. When talking to the internal support team or the
developer the first thing they ask for is "please send a
self-contained test case including an image of the failing file system".
They want to see an example because a lot of users do not understand the
compiler, the language or what is actually happening.
You have just proven my point. First-level support assumes the user is
too stupid to use the product,
|
The first line support I know are as capable and experienced as the
developers. There is usually little difference between the two
technically. The difference tends to be the developers are less tolerant
than the support guys. The support guys will also be able to answer most
questions faster because they have been asked them more than once.
| Quote: | and users with a clue have a hard time to
convince them that they actually know what they're talking about.
|
No more than talking to the developers.
What makes you so special and different to anyone else who calls?
| Quote: | In this particular case, the problem was in CD multisession handling,
thus "sending an image" would have meant to burn a CD and shipping it
over the ocean, along with our hardware because the reference hardware
has no CD drive. Expensive in time and money.
|
I think you have just proved my point. If you can't describe the problem
and encapsulate it without having to send the hardware and a complete CD
a compiler developer is less likely to want to talk to you than a
support person.
| Quote: | As for "it would have been fixed in a second" what is not true. You can
just change something in a compiler. You need to look very carefully at
what else it effects and do full regression tests (for the build) and
full tests (Plum hall, maths, language extensions, corner cases etc etc
but only AFTER you have looked to see if you need to add new tests. And
done all the documentation
The problematic code was about this:
char buffer[4];
fetch_buffer_somewhere(buffer);
address = buffer[0] + (buffer[1] << + (buffer[2] << 16)
+ (buffer[4] << 24);
I cannot imagine any situation where this is "more right" than
unsigned char buffer[4];
but I can imagine many situations where it is wrong. I would assume that
developers worth their money agree with me.
|
Assume makes an ass out of you and me...
| Quote: | Like many you see the problem and the solution far too simplistically.
Yeah right, I don't have a clue, I know.
|
Far be it for me to disagree with you
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |
|
| |
|
| Back to top |
CBFalconer
Guest
|
| Posted: Fri Nov 21, 2008 2:20 am Post subject: Re: ARM IDE |
|
|
Chris H wrote:
| Quote: | cbfalconer@yahoo.com> writes:
Chris H wrote:
David Brown <david.brown@hesbynett.removethisbit.no> writes:
... snip ...
Different system libraries might give different results in odd
cases). Do you test them all?
No. You are thinking GCC again. The compilers we test are supplied
with a single standard library. We test that. However it does
raise the point that will the GCC you have multiple libraries for
many sources. This makes it even more difficult to test GCC.
What about less usual circumstances, like running the windows
binary under Wine, or using some sort of virtualisation software?
We do not test it under those hosts. We state a specific host OS.
Emulations and virtual systems are up to you and you would need
to test on those systems for higher SIL.
How do you compensate for variations in parameter passing, calling
conventions, etc. in various libraries? Do you mean you have the
common library source, and compile it under each system?
We don't compile the library or the compiler. We don't start with
the source.
We test the library supplied with the compiler. We test on windows
XP, this is the host system for these compilers. They only run on
windows.
|
Alright. I misinterpreted your "with a single standard library. We
test that."
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section. |
|
| |
|
| Back to top |
Hans-Bernhard Bröker
Guest
|
| Posted: Fri Nov 21, 2008 2:28 am Post subject: Re: ARM IDE |
|
|
FreeRTOS.org wrote:
| Quote: | You are liable only if you have been neglegent.
|
Well, as the saying goes: At court and on the open sea, we're all in
God's hand.
You are liable if you are *found* negligent in a court of law. Now in
an ideal world people would only be found negligent if they actually did
neglect significant parts of their duties. But ours is, of course, not
an ideal world.
| Quote: | Somebody very high up in the FAA once said to me - "its impossible to
validate a compiler as there are an infinite number of inputs" [BTW: I
don't buy that statement myself].
|
On a similar note, it's impossible to validate any chip with more than
about 60 pins, simply on the grounds that even a test of all possible
combinations of static binary inputs to its pins (not to mention analog
inputs, voltage thresholds, timing, sequence, ...) would never finish
during the earth's life expectancy. |
|
| |
|
| Back to top |
David Brown
Guest
|
| Posted: Fri Nov 21, 2008 3:28 am Post subject: Re: ARM IDE |
|
|
Chris H wrote:
| Quote: | In message <gg2134.lc.1@stefan.msgid.phost.de>, Stefan Reuther
stefan.news@arcor.de> writes
Chris H wrote:
snip
. Everyone sees that this is wrong by looking at the code; I sent
file name and line number. The answer I got back was "please send a
self-contained test case including an image of the failing file system".
Had I been talking to a developer familiar with the code, not a support
guy, that would probably have been fixed that in a second.
Absolute bollax. When talking to the internal support team or the
developer the first thing they ask for is "please send a
self-contained test case including an image of the failing file system".
They want to see an example because a lot of users do not understand the
compiler, the language or what is actually happening.
Statistically I have found it worse amongst those who say "If I had the
source I could fix it" which is why I am very unconvinced when people
say having the course of a compiler is useful
|
You do realise he is talking about the source to the *library* here, not
the compiler? An experienced developer of a high level is going to be
just as capable of understanding, debugging and correcting a toolkit's
library as the library developers are - assuming there is decent
information available about things like calling and naming conventions
in the library. They are not going to be as skilled at specific tasks
such as writing the library code in a way that it compiles properly for
all its targets, and perhaps they are not going to write code as
optimally or portably. And they are certainly not going to be able to
run all the tests and qualifications.
But in situations like this one (and cases I have seen myself), the user
is perfectly capable of finding and correcting a bug in the library
source code if he has access to it. The fact is that some (by no means
all) compiler support lines cannot deal appropriately with this
situation. They either assume that the user is the problem, or they
follow rigid and inappropriate routines such as asking for complete
examples of the problem.
I agree that having the source to the *compiler* is not helpful to most
users when it comes to finding or fixing bugs (it can be useful for
other things, such as for changing development platform, archiving
tools, or as a safety net in case the compiler developers stop
development on the tools). But no one is talking about compiler source
code here. |
|
| |
|
| Back to top |
Walter Banks
Guest
|
| Posted: Fri Nov 21, 2008 3:28 am Post subject: Re: ARM IDE |
|
|
"FreeRTOS.org" wrote:
| Quote: | Out of interest, I have seen most bugs in generated code where non standard
features are used (like __interrupt qualifiers, etc.) and particularly
subtle stack frame problems that can be very reliant on particual events
occurring just at the wrong moment (temporal effects) - for example an
interrupt being taken just as another interrupt is being exited. The
interrupt entry/exit code being very hardware specific. Do the Plum Hall
tests pick up on that sort of thing?
|
No. Plum Hall and Perennial are language conformance tests. The kind of
feature you are describing is implementation specific and not covered.
Plum Hall and Perennial both are well respected as independent
test suites that validate language implementation against the standards.
Both companies are part if WG-14 and offer an independent view
of how the standard should be interpreted.
There is a lot of confusion about the meaning of successfully running
these test suites. Compiler companies run these as one of several
standard and private tests to validate and release compilers.
Regards
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com |
|
| |
|
| Back to top |
David Brown
Guest
|
| Posted: Fri Nov 21, 2008 4:00 am Post subject: Re: ARM IDE |
|
|
Chris H wrote:
| Quote: | In message <qu-dnVzkTpHOwbnUnZ2dnUVZ8vKdnZ2d@lyse.net>, David Brown
david.brown@hesbynett.removethisbit.no> writes
Chris H wrote:
is responsible for specific design and implementation decisions.
Quite so I can directly get in touch with all the developers and
project managers for any of the compilers I sell. Then again I have
NDAs with them as a distributor. So far I have not had any legitimate
question from a user that we have not been able to answer.
An end-user does not normally have these NDAs or this sort of
influence with the compiler companies - getting developer contact can
be hard or impossible if you are a small company with only one or a
few licenses. Going through a distributor (such as yourself) is one
way to get contact with the experts - assuming that all steps in the
chain are happy to help.
Yes. That is how it works. However the problem is that some questions
(and I have seen these questions sent simultaneously to several distis
and the compiler company) are answered on page 2 of the manual.
In many cases the person asking the question has very limited experience
and the language and the target and is asking the wrong question
completely. This is why compiler companies use first line support and
distis to weed out the idiots, simpletons and those who seem unable to
read the manual
The other point is I can discuss the problem with the end user and the
developer in more depth having an NDA in place. It helps I am a
qualified and experienced SW Engineer.
The problem is that once a user has the developers email address they
thing the have a personal friend and help line for life. The first port
of call (before the manual) is the developer.
Where I get any support from inside a company I always remove any direct
email addresses to the developers before passing on the information.
Getting direct access tot he developers doesn't happen in any other
industry.
BTW can the users of your companies products talk DIRECTLY to you about
the software functionality of your companies products?
|
I understand all about these support issues, and the reasons why it is
often undesirable to allow users direct contact with developers. I have
also been on the other side of the equation. Yes, we *do* have end
users who talk directly to myself and other software developers - not
many, but some experienced and technically competent end users have
direct contact. It can be of great benefit to both parties. I've also
had occasional direct contact with developers of hardware parts we buy -
again, it benefits both sides.
The important thing here is that we are talking about expert users - not
average users, and certainly not the "idiots, simpletons, and those who
seem unable to read the manual".
For almost all open source projects, many low-cost tools, and a fair
number of high-cost tools, a major source of support is from public web
forums, newsgroups, or mailing lists. A good public support forum is
frequented by the tools developers, as well as expert users who enjoy
using the tool, and are happy to help other users. Clearly there are
times when conventional technical support, either directly to the
suppliers or via a distributor, is better suited - for example, you
can't sign an NDA with a public forum.
| Quote: | Of course, that's a generalisation and there are plenty of exceptions.
I'm sure Bytecraft will give excellent support directly from the
developers, if we can judge by Walter Banks' contributions to this
public newsgroup
Where required they do.
. I have also had excellent technical support from ImageCraft - not
exactly a big player, but famous for their support.
Quite so.
|
Incidentally, the support I have had from ImageCraft has been mostly on
their mailing list, with many of the questions answered directly by the
developer. Many other people's questions have been answered by me, and
other "high level" users.
| Quote: | On the other hand, I have had technical issues with a big name
compiler in which I found a bug in their library. I even sent them a
fix for it. I was basically told that they don't care about the
problem, and that they were not going to fix it.
Interesting. Love to know who that was....
|
I'd prefer not to name names (especially as I can't remember which of
two possible suppliers it was...).
| Quote: | Technical support quality is definitely a widely varying priority for
different suppliers - part of the job of a distributor is to know and
recommend suppliers on such criteria.
Distributors recommend specific tools on many criteria. (btw there is no
universal "best" compiler for anything.... well that's not strictly
true. For some of the arcane MCU there are some times "the best" but in
other cases there are many factors to weigh up. None of the factors are
size of margin before you ask!
|
I have always been a fan of choosing the best tool for the job, and that
choice depends on many factors - technical support is only one of them.
| Quote: | More to the point with the complete version control they have they
can tell me EXACTLY who did which source file when and the full
history. Also they have all the supporting documentation. I doubt you
can do this with any version of GCC
I don't need to ask - I can simply look at the publicly available
source code repository:
http://gcc.gnu.org/viewcvs/
For EVERY version of GCC?
You know what all the code does and why it is there?
|
The quality of the logs and comments probably varies somewhat, as it
does in any project from any developers. But the history goes back a
fair way - look at <http://gcc.gnu.org/viewcvs?view=rev&revision=1>.
Of course, that particular source code repository is for the main FSF
gcc tree. There are a great many other gcc development trees for
different targets, experimental branches, or alternative development
branches. Some of these will be directly open to the public, others
will be internal to their developers (the GPL license requires you to
make the source code available along with binary releases, but makes no
requirements on the source history). If you are getting your gcc
binaries ready-made (such as from CodeSourcery) rather than checking out
and building your own copy, you might want to ask your particular
supplier about their source code tracking and logging. Of course,
CodeSourcery commit most of their changes back to the main FSF tree, so
you can look them up there. |
|
| |
|
| Back to top |
Chris H
Guest
|
| Posted: Fri Nov 21, 2008 9:17 am Post subject: Re: ARM IDE |
|
|
In message <gg4h90$do9$02$1@news.t-online.com>, Hans-Bernhard Bröker
<HBBroeker@t-online.de> writes
| Quote: | FreeRTOS.org wrote:
You are liable only if you have been neglegent.
Well, as the saying goes: At court and on the open sea, we're all in
God's hand.
You are liable if you are *found* negligent in a court of law. Now in
an ideal world people would only be found negligent if they actually
did neglect significant parts of their duties. But ours is, of course,
not an ideal world.
Somebody very high up in the FAA once said to me - "its impossible to
validate a compiler as there are an infinite number of inputs" [BTW:
I don't buy that statement myself].
On a similar note, it's impossible to validate any chip with more than
about 60 pins, simply on the grounds that even a test of all possible
combinations of static binary inputs to its pins (not to mention analog
inputs, voltage thresholds, timing, sequence, ...) would never finish
during the earth's life expectancy.
|
So you have to take "reasonable steps" to validate. As the industry
norm is to use certain test suites as part of it that is the standard.
If you can find another test suite of similar coverage (Perennial is
some 70,000 tests for a C compiler, written by known people who also
develop the standard) quite apart from the build and regression test
suites etc along with showing that care has been taken in the
development of the compiler (ie the process, specifications and
documentation etc) that that is OK.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |
|
| |
|
| Back to top |
Chris H
Guest
|
| Posted: Fri Nov 21, 2008 9:17 am Post subject: Re: ARM IDE |
|
|
In message <IuudncF2mMiaQ7jUnZ2dnUVZ8umdnZ2d@lyse.net>, David Brown
<david.brown@hesbynett.removethisbit.no> writes
| Quote: |
I understand all about these support issues, and the reasons why it is
often undesirable to allow users direct contact with developers. I
have also been on the other side of the equation. Yes, we *do* have
end users who talk directly to myself and other software developers -
not many, but some experienced and technically competent end users have
direct contact. It can be of great benefit to both parties. I've also
had occasional direct contact with developers of hardware parts we buy
- again, it benefits both sides.
|
This is true for compiler companies also. Some customers do get though
to the developers (though often the support team is more appropriate)
The trouble is "everyone" thinks they are an expert.
| Quote: | The important thing here is that we are talking about expert users -
not average users, and certainly not the "idiots, simpletons, and those
who seem unable to read the manual".
|
How do you tell them apart.... you the first line support weed them out.
BTW in many companies the developers do a spell on first line support,
in others the developers see the support calls on cc.
Usually If you can't get past first line support there is a reason for
that. The developers probably are aware of you and told support they
don't want to talk to you. Sorry if that hurts.
| Quote: | For almost all open source projects, many low-cost tools, and a fair
number of high-cost tools, a major source of support is from public web
forums, newsgroups, or mailing lists. A good public support forum is
frequented by the tools developers, as well as expert users who enjoy
using the tool, and are happy to help other users.
|
This is true. The developers usually go on these under fake names. Some
of the "expert users" are the developers. :-)
| Quote: | Clearly there are times when conventional technical support, either
directly to the suppliers or via a distributor, is better suited - for
example, you can't sign an NDA with a public forum.
|
Quite so.
| Quote: | I have always been a fan of choosing the best tool for the job, and
that choice depends on many factors - technical support is only one of
them.
|
A lot of it is where you have come from and where you want to go as much
as what you want to do now.
| Quote: | More to the point with the complete version control they have they
can tell me EXACTLY who did which source file when and the full
history. Also they have all the supporting documentation. I doubt
you can do this with any version of GCC
I don't need to ask - I can simply look at the publicly available
source code repository:
http://gcc.gnu.org/viewcvs/
For EVERY version of GCC?
You know what all the code does and why it is there?
The quality of the logs and comments probably varies somewhat, as it
does in any project from any developers. But the history goes back a
fair way - look at <http://gcc.gnu.org/viewcvs?view=rev&revision=1>.
Of course, that particular source code repository is for the main FSF
gcc tree. There are a great many other gcc development trees for
different targets, experimental branches, or alternative development
branches.
|
This is my point you can possibly validate a specific GCC binary but not
GCC per say. Nor GCC for "arm" or GCC from a part particular supplier.
| Quote: | Some of these will be directly open to the public, others will be
internal to their developers (the GPL license requires you to make the
source code available along with binary releases, but makes no
requirements on the source history).
|
When we validate compilers we normally have to sign an NDA and have an
internal view of their development
| Quote: | If you are getting your gcc binaries ready-made (such as from
CodeSourcery) rather than checking out and building your own copy, you
might want to ask your particular supplier about their source code
tracking and logging.
|
This would be essential. I am sure Code Sorcery can supply this. However
you would only be validating that part ticular version of the binary
form CS. Not GCC or the source.
| Quote: | Of course, CodeSourcery commit most of their changes back to the main
FSF tree, so you can look them up there.
|
"Most" that is the problem. GCC is developed asynchronously by multiple
sources who may or may not feed their changes back to the FSF
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |
|
| |
|
| Back to top |
Chris H
Guest
|
| Posted: Fri Nov 21, 2008 9:17 am Post subject: Re: ARM IDE |
|
|
In message <4925D675.633DEAB6@bytecraft.com>, Walter Banks
<walter@bytecraft.com> writes
| Quote: |
"FreeRTOS.org" wrote:
Out of interest, I have seen most bugs in generated code where non standard
features are used (like __interrupt qualifiers, etc.) and particularly
subtle stack frame problems that can be very reliant on particual events
occurring just at the wrong moment (temporal effects) - for example an
interrupt being taken just as another interrupt is being exited. The
interrupt entry/exit code being very hardware specific. Do the Plum Hall
tests pick up on that sort of thing?
No. Plum Hall and Perennial are language conformance tests. The kind of
feature you are describing is implementation specific and not covered.
Plum Hall and Perennial both are well respected as independent
test suites that validate language implementation against the standards.
Both companies are part if WG-14 and offer an independent view
of how the standard should be interpreted.
There is a lot of confusion about the meaning of successfully running
these test suites. Compiler companies run these as one of several
standard and private tests to validate and release compilers.
|
My point has been there are no comparable tests done on the GCC
compilers in general. One or two specific versions from specific vendors
are tested well but that only covers the specific binary tested. NOT the
source code.
SO in general GCC is not as a family validatable Just specific binaries
if you can get access to the company that does that binary.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |
|
| |
|
| Back to top |
Chris H
Guest
|
| Posted: Fri Nov 21, 2008 9:17 am Post subject: Re: ARM IDE |
|
|
In message <C5idnS6fWt4aS7jUnZ2dnUVZ8r6dnZ2d@lyse.net>, David Brown
<david.brown@hesbynett.removethisbit.no> writes
| Quote: | Statistically I have found it worse amongst those who say "If I had
the source I could fix it" which is why I am very unconvinced when
people say having the course of a compiler is useful
You do realise he is talking about the source to the *library* here,
not the compiler? An experienced developer of a high level is going to
be just as capable of understanding, debugging and correcting a
toolkit's library as the library developers are - assuming there is
decent information available about things like calling and naming
conventions in the library.
|
Possibly, maybe and not normally. That said several commercial
compilers do make the library source available its just not FOSS.
| Quote: | They are not going to be as skilled at specific tasks such as writing
the library code in a way that it compiles properly for all its
targets, and perhaps they are not going to write code as optimally or
portably. And they are certainly not going to be able to run all the
tests and qualifications.
|
So you have an untested and unqualified non-standard library....
| Quote: | But in situations like this one (and cases I have seen myself), the
user is perfectly capable of finding and correcting a bug in the
library source code if he has access to it.
|
The problem is that will out the full regression tests the user has no
idea if he has fixed the bug without causing any other problems. See
the definition of debugging :-)
http://www.phaedsys.com/resources/posters/define.pdf
| Quote: | The fact is that some (by no means all) compiler support lines cannot
deal appropriately with this situation. They either assume that the
user is the problem, or they follow rigid and inappropriate routines
such as asking for complete examples of the problem.
|
Normally
They don't assume the user is the problem .
Asking for a complete example is not inappropriate.
Often what the user reports and what they are actually doing and what
they are trying to do are three different things.
| Quote: | I agree that having the source to the *compiler* is not helpful to most
users when it comes to finding or fixing bugs
|
I am glad that we agree on that. You are there to USE the tools to
develop you products. Not to develop the tools
| Quote: | (it can be useful for other things, such as for changing development
platform,
I don t see how. See above. |
| Quote: | archiving tools,
Not really. You need to archive the actual binary you are using,. |
(Possibly with a PC to run it on.
| Quote: | or as a safety net in case the compiler developers stop development on
the tools).
Why would you need the source here? |
| Quote: | But no one is talking about compiler source code here.
? What were you talking about? |
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |
|
| |
|
| Back to top |
Everett M. Greene
Guest
|
| Posted: Fri Nov 21, 2008 5:11 pm Post subject: Re: ARM IDE |
|
|
David Brown <david.brown@hesbynett.removethisbit.no> writes:
| Quote: | I understand all about these support issues, and the reasons why it is
often undesirable to allow users direct contact with developers. I have
also been on the other side of the equation. Yes, we *do* have end
users who talk directly to myself and other software developers - not
many, but some experienced and technically competent end users have
direct contact. It can be of great benefit to both parties. I've also
had occasional direct contact with developers of hardware parts we buy -
again, it benefits both sides.
The important thing here is that we are talking about expert users - not
average users, and certainly not the "idiots, simpletons, and those who
seem unable to read the manual".
For almost all open source projects, many low-cost tools, and a fair
number of high-cost tools, a major source of support is from public web
forums, newsgroups, or mailing lists. A good public support forum is
frequented by the tools developers, as well as expert users who enjoy
using the tool, and are happy to help other users. Clearly there are
times when conventional technical support, either directly to the
suppliers or via a distributor, is better suited - for example, you
can't sign an NDA with a public forum.
|
What's more than annoying is to have an NDA in place with
a hardware manufacturer and then not be able to make
contact with anyone with knowledge of the product in
question. Or contact is made and the contact never
replies. |
|
| |
|
| Back to top |
|
