Bug in latest IAR MSP430 compiler optimization???
larwe
from IAR has an extremely serious code generation bug when configured
with optimizations=high,size?
IAR C/C++ Compiler for MSP430
V4.10E/W32 [Kickstart] (4.10.5.3)
C:\Program Files\IAR Systems\Embedded Workbench 5.0\430\bin\icc430.exe
2/15/2008 11:03:06 AM, 15015936 bytes
I have a test case that demos the problem perfectly, but it's tied to
specific hardware. The symptom is that a pointer, if declared locally,
is being sent off into random-land after one iteration of a loop. If
the same declaration is moved out into global scope, or if
optimization is turned off, the problem disappears. Target is
MSP430F2012.
I haven't yet groveled through the assembly output to see exactly what
the difference between the two output flavors is. But this is such an
astoundingly show-stopping bug I'm appalled it escaped.
Chris H
<1b8713e7-1edf-401c...@s33g2000pri.googlegroups.com>,
larwe <zwsd...@gmail.com> writes
What did IAR support say about it when you told them?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
larwe
> >I haven't yet groveled through the assembly output to see exactly what
> >the difference between the two output flavors is. But this is such an
> >astoundingly show-stopping bug I'm appalled it escaped.
>
> What did IAR support say about it when you told them?
Kickstart has no support. Of course, last time I was working with a
bought version of their compiler, and found a [different] bug, the
answer was "buy the latest upgrade".
Chris H
<4e894752-5193-471a...@w5g2000prd.googlegroups.com>,
larwe <zwsd...@gmail.com> writes
>On Apr 27, 8:33 am, Chris H <ch...@phaedsys.org> wrote:
>
>> >I haven't yet groveled through the assembly output to see exactly what
>> >the difference between the two output flavors is. But this is such an
>> >astoundingly show-stopping bug I'm appalled it escaped.
>>
>> What did IAR support say about it when you told them?
>
>Kickstart has no support.
Of course not it is a FREE size limited eval version. However that does
not mean you can't report bugs to the support team. Why wouldn't you?
>Of course, last time I was working with a
>bought version of their compiler, and found a [different] bug, the
>answer was "buy the latest upgrade".
Because you had a very old version (IAR compilers have 12 months
support) and they had fixed the bug in a later version. It would only
be "buy" a new version if you were out of support. Which you would be or
you would have got the update for free.
You do like trying to make mountains out of molehills.
If you find a bug in ANY compiler (not just IAR) that is fixed in a
newer version they tell you to get the latest version. If you are on
support it is usually free. You only have to pay if it is a very old
version.
However if you want to use an old version that is your look out.
Vladimir Vassilevsky
larwe wrote:
> Has anyone else observed that the latest kickstart MSP430 compiler
> from IAR has an extremely serious code generation bug when configured
> with optimizations=high,size?
>
> The symptom is that a pointer, if declared locally,
> is being sent off into random-land after one iteration of a loop. If
> the same declaration is moved out into global scope, or if
> optimization is turned off, the problem disappears.
I am not particularly familiar with IAR for MSP430, however I have seen
several times that the IAR for AVR can loose a local variable if the
function is complex enough and the optimization is set to maximum.
Declaring this variable as static helps.
> I haven't yet groveled through the assembly output to see exactly what
> the difference between the two output flavors is. But this is such an
> astoundingly show-stopping bug I'm appalled it escaped.
Why are you so astounded? *Every* C/C++ compiler that I ever worked with
did have bugs. If one doesn't see any bugs in compiler, that simply
means that he haven't yet done any serious projects with it.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
Vladimir Vassilevsky
Chris H wrote:
> If you find a bug in ANY compiler (not just IAR) that is fixed in a
> newer version they tell you to get the latest version.
Sure. The latest version of compiler with the fresh not yet known bugs.
Porting a working project to the next revision of a compiter is PITA.
> If you are on
> support it is usually free. You only have to pay if it is a very old
> version.
> However if you want to use an old version that is your look out.
Yes, this is one of the problems. They can't make money from just making
bug fixes to the current software, so they have to release new versions.
There is a phylosophycal principle: "It is better to be the first, then
to be the best". I wonder if it is a universal law or just a current
direction of the development of the civilization.
Chris H
Vassilevsky <antispa...@hotmail.com> writes
>Chris H wrote:
>> If you find a bug in ANY compiler (not just IAR) that is fixed in a
>>newer version they tell you to get the latest version.
>Sure. The latest version of compiler with the fresh not yet known bugs.
>Porting a working project to the next revision of a compiter is PITA.
Then don't use a compiler.
>> If you are on support it is usually free. You only have to pay if
>>it is a very old version.
>> However if you want to use an old version that is your look out.
>Yes, this is one of the problems. They can't make money from just
>making bug fixes to the current software, so they have to release new
>versions.
If you fix bugs in a compiler you get a new version. These are usually
free in the first year after purchase as part of the compiler price.
It cost money to do support and continue development. How would you fund
it? Triple the cost of the compiler to start with to cover the ongoing
work?
>There is a phylosophycal principle: "It is better to be the first, then
>to be the best".
This does not apply to compilers. You seem to understand very little.
The problem with compilers is that it is never ending.
As you appear not to know silicon vendors fix and patch chips requiring
changes to the compiler. Silicon vendors release new version and
additions to the family requiring changes to the compiler. The C
standard changes (frequently) requiring changes to the compiler and or
the library. Then there are changes to the simulator and linker for
many of the reasons above.
Then there are changes to Windows that affect the whole system...
Compiler development is an on going task. Not a 1 off release. I recall
a customer complaining to me that he should have a free upgrade to a 6
year old compiler because it did not support a new part (with new memory
system) that had just been released!
> I wonder if it is a universal law or just a current direction of the
>development of the civilization.
It is a universal law of civilisation since the dawn of time.
However most software tools tend to go for small changes and release
often after the initial release.
Vladimir Vassilevsky
Chris H wrote:
> Chris H wrote:
>>
>>> If you find a bug in ANY compiler (not just IAR) that is fixed in a
>>> newer version they tell you to get the latest version.
>>
>> Sure. The latest version of compiler with the fresh not yet known
>> bugs. Porting a working project to the next revision of a compiter is
>> PITA.
>
> Then don't use a compiler.
I prefer keeping the projects with the complete old toolchains and not
to jump to the latest and greatest unless it is really required. If a
compiler bug was spotted, then it is not dangerous any more.
>
>>> If you are on support it is usually free. You only have to pay if
>>> it is a very old version.
>>> However if you want to use an old version that is your look out.
>>
>> Yes, this is one of the problems. They can't make money from just
>> making bug fixes to the current software, so they have to release new
>> versions.
>
> If you fix bugs in a compiler you get a new version.
If you fixed the bugs you only got a new build of the old version. By
releasing the bug fixes you acknowledged that you can't get the things
right at the first time, however the good thing is that you care. The
new version should have a difference.
> These are usually
> free in the first year after purchase as part of the compiler price.
>
> It cost money to do support and continue development. How would you fund
> it? Triple the cost of the compiler to start with to cover the ongoing
> work?
This is the problem of the compiler people, not mine. What point are you
trying to make? I have no illusion that the compiler development is
different from any other sw development. Same kind of lousy and pitifull
business.
>
>> There is a phylosophycal principle: "It is better to be the first,
>> then to be the best".
>
> This does not apply to compilers. You seem to understand very little.
> The problem with compilers is that it is never ending.
>
> As you appear not to know silicon vendors fix and patch chips requiring
> changes to the compiler. Silicon vendors release new version and
> additions to the family requiring changes to the compiler. The C
> standard changes (frequently) requiring changes to the compiler and or
> the library. Then there are changes to the simulator and linker for
> many of the reasons above.
The life is hard. Is that what you are trying to prove?
> Then there are changes to Windows that affect the whole system...
Sure. Let's blame Bill Gates for everything.
> Compiler development is an on going task. Not a 1 off release. I recall
> a customer complaining to me that he should have a free upgrade to a 6
> year old compiler because it did not support a new part (with new memory
> system) that had just been released!
Not my problem.
>> I wonder if it is a universal law or just a current direction of the
>> development of the civilization.
>
> It is a universal law of civilisation since the dawn of time.
>
> However most software tools tend to go for small changes and release
> often after the initial release.
Oh well. I'd better go join the linuxopaths with their GCC...
David Brown
There's a difference here between what is often termed "updates" and
"upgrades". An "upgrade" means a new versions of the tool, typically
with new features, and is something you can only expect to get while on
a support contract of some kind. You don't "upgrade" the tools you use
for a project without good reason, and when a project is finished, you
keep track of the tool versions used in its development.
"updates" (or "service packs"), on the other hand, are minor changes -
often bug fixes, but occasionally small additional changes (perhaps
support for a new chip variant). They are usually safe to use without
changing your project, and are often freely available to any licensed user.
Thus changing from gcc 4.2.2 to gcc 4.3.0 is an upgrade, and may require
changes to the project. Changing to 4.2.3 is merely an update to fix a
couple of bugs.
It is not unreasonable to expect a compiler supplier to provide updates
for a certain time after purchase - you should not have to upgrade just
to get a bug fix. (Note that I have no idea what IAR's policy is in
this - I'm just expressing general comments.)
Chris H
Vassilevsky <antispa...@hotmail.com> writes
>
>
>Chris H wrote:
>
>> Chris H wrote:
>>>
>>>> If you are on support it is usually free. You only have to pay
>>>>if it is a very old version.
>>>> However if you want to use an old version that is your look out.
>>>
>>> Yes, this is one of the problems. They can't make money from just
>>>making bug fixes to the current software, so they have to release new
>>>versions.
>> If you fix bugs in a compiler you get a new version.
>
>If you fixed the bugs you only got a new build of the old version.
No it is a new version
>> These are usually free in the first year after purchase as part of
>>the compiler price.
>> It cost money to do support and continue development. How would you
>>fund it? Triple the cost of the compiler to start with to cover the
>>ongoing work?
>
>This is the problem of the compiler people, not mine. What point are
>you trying to make? I have no illusion that the compiler development is
>different from any other sw development. Same kind of lousy and
>pitifull business.
So your software development is a "lousy and pitiful business" and you
judge all the rest by your standards?
Chris H
<david...@hesbynett.removethisbit.no> writes
>Vladimir Vassilevsky wrote:
>> Chris H wrote:
>>
>>> Chris H wrote:
>>>>
>>>>> If you find a bug in ANY compiler (not just IAR) that is fixed in
>>>>>a newer version they tell you to get the latest version.
>It is not unreasonable to expect a compiler supplier to provide updates
>for a certain time after purchase - you should not have to upgrade just
>to get a bug fix. (Note that I have no idea what IAR's policy is in
>this - I'm just expressing general comments.)
IAR in common with nearly all compilers I know of give you free updates
AND upgrades for 12 months. After that you have to buy support.
Gene S. Berkowitz
says...
> In message
> <4e894752-5193-471a...@w5g2000prd.googlegroups.com>,
> larwe <zwsd...@gmail.com> writes
> >On Apr 27, 8:33 am, Chris H <ch...@phaedsys.org> wrote:
> >
> >> >I haven't yet groveled through the assembly output to see exactly what
> >> >the difference between the two output flavors is. But this is such an
> >> >astoundingly show-stopping bug I'm appalled it escaped.
> >>
> >> What did IAR support say about it when you told them?
> >
> >Kickstart has no support.
>
> Of course not it is a FREE size limited eval version. However that does
> not mean you can't report bugs to the support team. Why wouldn't you?
>
> >Of course, last time I was working with a
> >bought version of their compiler, and found a [different] bug, the
> >answer was "buy the latest upgrade".
>
> Because you had a very old version (IAR compilers have 12 months
> support) and they had fixed the bug in a later version. It would only
> be "buy" a new version if you were out of support. Which you would be or
> you would have got the update for free.
>
> You do like trying to make mountains out of molehills.
>
> If you find a bug in ANY compiler (not just IAR) that is fixed in a
> newer version they tell you to get the latest version. If you are on
> support it is usually free. You only have to pay if it is a very old
> version.
>
> However if you want to use an old version that is your look out.
Following is what the latest Kickstart version I have (came with the
EZ2500 kit) says when About... is clicked. Considering that practically
every component has a different version and build #, it's virtually
impossible to ever say with certainty what "version" of IAR anyone has.
--Gene
IAR Assembler for MSP430
V4.09A/W32 (4.9.1.9)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\a430.exe
9/26/2007 9:38:38 AM, 688128 bytes
IAR C/C++ Compiler for MSP430
V4.09A/W32 [Kickstart] (4.9.1.3)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\icc430.exe
9/26/2007 9:27:24 AM, 9121792 bytes
Uninstall Program for FTDI Drivers
3.0.0.33 (3.0.0.33)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\drivers\Olimex
\FTDIUNIN.exe
9/26/2007 1:27:04 PM, 420864 bytes
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\drivers\Olimex
\omjtunin.exe
9/26/2007 1:27:04 PM, 28672 bytes
Windows Setup API
5.1.2600.0 built by: WinDDK (5.1.2600.0)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\drivers\Olimex
\omjtunin2k.exe
9/26/2007 1:27:04 PM, 47616 bytes
PreInstaller MFC Application
1, 0, 0, 1 (1.0.0.1)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\drivers\Olimex
\PreInstaller.exe
9/26/2007 1:27:04 PM, 32768 bytes
Uninstall Program for FTDI D2XX Drivers
2.2.0.2 (2.2.0.2)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\drivers
\SoftBaugh\FTD2XXUN.EXE
9/26/2007 1:26:58 PM, 406528 bytes
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\src\examples
\Segger\embOS\embOSView.exe
9/26/2007 1:28:34 PM, 53760 bytes
IAR CSpyBat
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\CSpyBat.exe
9/25/2007 1:53:50 PM, 270336 bytes
IAR Build Utility
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\iarbuild.exe
9/25/2007 1:53:50 PM, 69632 bytes
IAR Embedded Workbench IDE
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\IarIdePm.exe
9/25/2007 1:53:50 PM, 364544 bytes
IAR Library Builder
1.03L (1.3.12.0)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin\xar.exe
8/31/2007 2:02:14 PM, 98304 bytes
IAR XLIB
3.29P/386 (3.29.0.16)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin\xlib.exe
8/31/2007 2:03:18 PM, 425984 bytes
IAR XLINK
4.60K (4.60.11.0)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin\xlink.exe
8/31/2007 3:03:52 PM, 1388544 bytes
IAR C-SPY Batch Simulator Driver for MSP430
V4.09A/W32 (4.9.1.9)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\430bat.dll
9/25/2007 3:16:50 PM, 270336 bytes
IAR C-SPY Emulator Driver for MSP430
V4.09A/W32 [Kickstart] (4.9.1.3)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\430fet.dll
9/25/2007 3:04:06 PM, 892928 bytes
IAR C-SPY Library Support Plug-in for MSP430
V4.09A/W32 (4.9.1.9)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin
\430libsupport.dll
9/25/2007 3:15:48 PM, 376832 bytes
IAR C-SPY Processor Descriptor for MSP430
V4.09A/W32 (4.9.1.9)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\430proc.dll
9/25/2007 3:15:36 PM, 1179648 bytes
IAR C-SPY Simulator Driver for MSP430
V4.09A/W32 [Kickstart] (4.9.1.3)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\430sim.dll
9/25/2007 2:59:20 PM, 1228800 bytes
CP210x
1.2 (1.2.0.0)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin
\CP210xManufacturing.dll
9/26/2007 1:30:04 PM, 69632 bytes
IAR Project File Converter for MSP430
V3.21A/W32 (3.21.1.9)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\cwtd430.dll
9/26/2007 1:27:06 PM, 352256 bytes
FTD2XX library
3.01.06 (3.1.6.1)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\FTD2XX.dll
9/26/2007 1:30:04 PM, 81920 bytes
HIL
1, 2, 2, 0 (1.2.2.0)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\hil.dll
9/26/2007 1:30:04 PM, 32768 bytes
SEGGER J-Link MSP430 interface DLL
2.1.1.0 (2.1.1.0)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\JLink430.dll
9/26/2007 1:30:04 PM, 114688 bytes
MSP430.dll for the USB-MSP430-FPA v10.0
2, 1, 10, 0 (2.1.10.0)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\MSP430-
FPA.dll
9/26/2007 1:30:04 PM, 348160 bytes
MSP430
Version (2.3.1.0)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\msp430.dll
9/26/2007 1:30:04 PM, 225280 bytes
MSP430
1, 0, 1, 1 (1.0.1.1)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\olimex.dll
9/26/2007 1:30:06 PM, 458752 bytes
SBMSP430_DLL DLL
2, 1, 8, 1 (2.1.8.1)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\sbmsp430.dll
9/26/2007 1:30:06 PM, 258048 bytes
SiUSBXp
2, 3, 0, 0 (2.3.0.0)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\SiUSBXp.dll
9/26/2007 1:30:06 PM, 90112 bytes
MSP430
Version (2.1.8.1)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin
\SoftBaugh.dll
9/26/2007 1:30:06 PM, 32768 bytes
IAR Workbench Target Descriptor for MSP430
V4.09A/W32 (4.9.1.9)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\swtd430.dll
9/25/2007 3:16:40 PM, 749568 bytes
IAR Workbench Target Descriptor, Emulator, for MSP430
V4.09A/W32 (4.9.1.9)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin
\swtd430fet.dll
9/25/2007 2:45:40 PM, 360448 bytes
IAR Workbench Target Descriptor, Simulator, for MSP430
V4.09A/W32 (4.9.1.9)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin
\swtd430sim.dll
9/25/2007 2:59:54 PM, 294912 bytes
FTD2XX library
3.00.05 (3.0.5.1)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\drivers\Olimex
\FTD2XX.dll
9/26/2007 1:27:04 PM, 81920 bytes
FTD2XX library
2.00.11 (2.0.11.1)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\drivers
\SoftBaugh\FTD2XX.dll
9/26/2007 1:26:58 PM, 69632 bytes
LCD Plugin for EW430
3.42A (3.42.1.9)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\plugins\Lcd
\lcd.dll
9/26/2007 2:06:54 PM, 266240 bytes
SEGGER embOS IAR-Plugin
2, 0, 5, 0 (2.0.5.0)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\plugins\rtos
\embOS\embOSPlugin.dll
9/26/2007 1:28:34 PM, 397312 bytes
µC/OS-II KA Plug-in for C-SPY DLL
2.50 2007-09-10 (2.5.0.0)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\plugins\rtos
\uCOS-II\uCOS-II-KA-CSpy.dll
9/26/2007 1:28:34 PM, 339968 bytes
IAR CSpyBat Language Specific Resources
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\CSpyBat.ENU.dll
9/25/2007 1:53:50 PM, 4608 bytes
IAR C-SPY Debugger GUI
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\DebuggerGui.dll
9/25/2007 1:53:50 PM, 1159168 bytes
IAR C-SPY Debugger GUI Language Specific Resources
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\DebuggerGui.ENU.dll
9/25/2007 1:53:50 PM, 73728 bytes
IAR Find In Files
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\FindInFiles.dll
9/25/2007 1:53:50 PM, 188416 bytes
IAR Find In Files Language Specific Resources
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\FindInFiles.ENU.dll
9/25/2007 1:53:50 PM, 5632 bytes
IAR Build Utility Language Specific Resources
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\iarbuild.ENU.dll
9/25/2007 1:53:50 PM, 4096 bytes
IAR Embedded Workbench IDE Language Specific Resources
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\IarIdePm.ENU.dll
9/25/2007 1:53:50 PM, 479232 bytes
IAR IDE Framework
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\IdeFramework.dll
9/25/2007 1:53:50 PM, 655360 bytes
IAR IDE Framework Language Specific Resources
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\IdeFramework.ENU.dll
9/25/2007 1:53:50 PM, 5120 bytes
IAR C-SPY Debugger Kernel
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\Kernel.dll
9/25/2007 1:53:50 PM, 1576960 bytes
IAR C-SPY Debugger Kernel Language Specific Resources
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\Kernel.ENU.dll
9/25/2007 1:53:50 PM, 8192 bytes
IAR Log Window
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\LogWindow.dll
9/25/2007 1:53:50 PM, 212992 bytes
IAR Log Window Language Specific Resources
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\LogWindow.ENU.dll
9/25/2007 1:53:50 PM, 11264 bytes
IAR Project Manager Engine
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\ProjectManagerEngine.dll
9/25/2007 1:53:50 PM, 1073152 bytes
IAR Project Manager Engine Language Specific Resources
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\ProjectManagerEngine.ENU.dll
9/25/2007 1:53:50 PM, 13824 bytes
IAR Project Manager Gui
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\ProjectManagerGui.dll
9/25/2007 1:53:50 PM, 708608 bytes
IAR Project Manager Gui Language Specific Resources
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\ProjectManagerGui.ENU.dll
9/25/2007 1:53:50 PM, 106496 bytes
IAR Text Editor
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\TextEditor.dll
9/25/2007 1:53:50 PM, 491520 bytes
IAR Text Editor Language Specific Resources
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\TextEditor.ENU.dll
9/25/2007 1:53:50 PM, 26112 bytes
Shared Library for Xerces-C Version 1.5.1
1, 5, 1 (1.5.1.0)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin\xerces-c_
1_5_1.dll
9/25/2007 1:53:48 PM, 1257472 bytes
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\bin
\XmlLib.dll
9/25/2007 1:53:48 PM, 90112 bytes
IAR Code Coverage Plug-in
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\plugins
\CodeCoverage\CodeCoverage.dll
9/25/2007 1:53:48 PM, 303104 bytes
IAR Code Coverage Plug-in Language Specific Resources
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\plugins
\CodeCoverage\CodeCoverage.ENU.dll
9/25/2007 1:53:48 PM, 10752 bytes
IAR ORTI RTOS Plug-in
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\plugins\Orti
\Orti.dll
9/25/2007 1:53:48 PM, 413696 bytes
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\plugins\Orti
\Orti.ENU.dll
9/25/2007 1:53:48 PM, 8704 bytes
IAR Profiling Plug-in
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\plugins
\Profiling\Profiling.dll
9/25/2007 1:53:48 PM, 299008 bytes
IAR Profiling Plug-in Language Specific Resources
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\plugins
\Profiling\Profiling.ENU.dll
9/25/2007 1:53:48 PM, 10752 bytes
IAR Stack Plug-in
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\plugins\Stack
\Stack.dll
9/25/2007 1:53:48 PM, 331776 bytes
IAR Stack Plug-in Language Specific Resources
5.0.1.254.6782 (5.0.1.254)
D:\Program Files\IAR Systems\Embedded Workbench 4.0\common\plugins\Stack
\Stack.ENU.dll
9/25/2007 1:53:48 PM, 8192 bytes
Chris H
Berkowitz <first...@verizon.net> writes
As with ALL compiler suites. You are either being deliberately obtuse or
don't understand the tools. Neither trait is good for a developer.
The package has a release number (on the CD, zip file etc) and the
individual components also have release numbers as you listed. It is
called version control. Something that happens in professional software
development.
I used to have this problem a lot with Keil C51 when asking what version
of the compiler someone was using. I often got the version of the IDE.
Vladimir Vassilevsky
Chris H wrote:
>> I have no illusion that the compiler development
>> is different from any other sw development. Same kind of lousy and
>> pitifull business.
>
>
> So your software development is a "lousy and pitiful business" and you
> judge all the rest by your standards?
>
The software development is lousy and pitiful business. The ones who
state the different either have no clue, or deliberately lying, or never
wrote anything longer then "Hello World".
Grant Edwards
> On Apr 27, 8:33?am, Chris H <ch...@phaedsys.org> wrote:
>
>> >I haven't yet groveled through the assembly output to see exactly what
>> >the difference between the two output flavors is. But this is such an
>> >astoundingly show-stopping bug I'm appalled it escaped.
>>
>> What did IAR support say about it when you told them?
>
> Kickstart has no support.
That may be true de jure, but not de facto. If you report the
bug on the MSP430 mailing list, I'd bet a doughnut that
somebody from IAR will respond.
> Of course, last time I was working with a bought version of
> their compiler, and found a [different] bug, the answer was
> "buy the latest upgrade".
Um, that's pretty much how commercial software works. If you
were using mspgcc, you could just fix the problem, submit the
patch, and get on with your work. Worst case, you could report
the problem and wait for a day or two while somebody else
fixes it. For free.
--
Grant Edwards grante Yow! We're going to a
at new disco!
visi.com
Chris H
Vassilevsky <antispa...@hotmail.com> writes
>
>
>Chris H wrote:
>
>
>>> I have no illusion that the compiler development is different from
>>>any other sw development. Same kind of lousy and pitifull business.
>> So your software development is a "lousy and pitiful business" and
>>you judge all the rest by your standards?
>>
>
>The software development is lousy and pitiful business. The ones who
>state the different either have no clue, or deliberately lying, or
>never wrote anything longer then "Hello World".
Well you are wrong on all three counts.
Perhaps it is just your world.
Mark Borgerson
says...
> On 2008-04-27, larwe <zwsd...@gmail.com> wrote:
> > On Apr 27, 8:33?am, Chris H <ch...@phaedsys.org> wrote:
> >
> >> >I haven't yet groveled through the assembly output to see exactly what
> >> >the difference between the two output flavors is. But this is such an
> >> >astoundingly show-stopping bug I'm appalled it escaped.
> >>
> >> What did IAR support say about it when you told them?
> >
> > Kickstart has no support.
>
> That may be true de jure, but not de facto. If you report the
> bug on the MSP430 mailing list, I'd bet a doughnut that
> somebody from IAR will respond.
>
> > Of course, last time I was working with a bought version of
> > their compiler, and found a [different] bug, the answer was
> > "buy the latest upgrade".
>
> Um, that's pretty much how commercial software works. If you
> were using mspgcc, you could just fix the problem, submit the
> patch, and get on with your work.
I'm not sure that someone qualified to write good embedded
code for the MSP430 is also qualified to patch the code
generator of mspgcc.
I've written a lot of embedded code for the MSP430 and other
embedded systems, but I've never even LOOKED at the source
for the code generator of any compiler! That may be because
I got into embedded systems from oceanography---and have
never taken any computer science course other than a freshman
introductory course---and that in 1968! Oddly enough,
I did teach computer science at the U for a few years---sophomore
and junior level courses in architecture and assembly-language
programming.
> Worst case, you could report
> the problem and wait for a day or two while somebody else
> fixes it. For free.
>
>
Mark Borgerson
Chris H
Borgerson <mborg...@comcast.net> writes
>> were using mspgcc, you could just fix the problem, submit the
>> patch, and get on with your work.
>
>I'm not sure that someone qualified to write good embedded
>code for the MSP430 is also qualified to patch the code
>generator of mspgcc.
I would agree... most only think they are.
Chris H
>
>> >I haven't yet groveled through the assembly output to see exactly what
>> >the difference between the two output flavors is. But this is such an
>> >astoundingly show-stopping bug I'm appalled it escaped.
>>
>> What did IAR support say about it when you told them?
>
>Kickstart has no support.
Their response to a bug in
>IAR C/C++ Compiler for MSP430
>V4.10E/W32 [Kickstart] (4.10.5.3)
IE a Kickstart compiler that has "no support" was:-
///////////////////
It is documented that Hi optimization level is a very very aggressive
level that must be always tested against the application. At level LOW
the user will get ALL the industry standard optimization techniques,
most of the new techniques are represented at the hi level.
There are several guidelines how to deal with these situation, the IAR
compiler support optimization on the function level, using #prgama
optimization in case you really want to use the high level, declaring
variables as volatile will help the optimizer decide whether to optimize
out a variable or not, avoiding empty delay loops and simply including a
__no_operation() intrinsic function inside an empty loop will help the
optimizer decide etc... If you have a specific sample code that we can
compile and link and debug, then send it over to fwd to development .
///////////////////
So it is Documented... You did read the documentation? If you would like
to send IAR some sample code they will look at the problem.
So much for "no support" you did not even ask!
You just made assumptions and tried to discredit a compiler company.
Rather unprofessional of you to say the least.
Grant Edwards
>>> Of course, last time I was working with a bought version of
>>> their compiler, and found a [different] bug, the answer was
>>> "buy the latest upgrade".
>>
>> Um, that's pretty much how commercial software works. If you
>> were using mspgcc, you could just fix the problem, submit the
>> patch, and get on with your work.
>
> I'm not sure that someone qualified to write good embedded
> code for the MSP430 is also qualified to patch the code
> generator of mspgcc.
Possibly not. Then you've the option of waiting for somebody
else to fix it or paying somebody else to fix it.
--
Grant Edwards grante Yow! I want to mail a
at bronzed artichoke to
visi.com Nicaragua!
larwe
> I'm not sure that someone qualified to write good embedded
> code for the MSP430 is also qualified to patch the code
> generator of mspgcc.
I've only known two people that had real professional level
understanding at both ends of the spectrum, to the degree where I
would feel comfortable hiring them for either role. Both of those
people are, incidentally dead.
I've patched XFree86 and Linux and a couple of other major major
projects, but I never even felt the slightest desire to dabble in
gcc's sources. Wouldn't consider it, in this case. It would be a
situation of making the furnace to smelt the iron to make the hammer
to bang in the nail.
Clifford Heath
> I've only known two people that had real professional level
> understanding at both ends of the spectrum, to the degree where I
> would feel comfortable hiring them for either role. Both of those
> people are, incidentally dead.
I hope that's not an occupational hazard for such people, because
I've done both these things :-).
Grant Edwards
>>> Of course, last time I was working with a bought version of
>>> their compiler, and found a [different] bug, the answer was
>>> "buy the latest upgrade".
>>
>> Um, that's pretty much how commercial software works. If you
>> were using mspgcc, you could just fix the problem, submit the
>> patch, and get on with your work.
>
> I'm not sure that someone qualified to write good embedded
> code for the MSP430 is also qualified to patch the code
> generator of mspgcc.
It's not that hard. I've done a few fixes and feature
additions to gcc, binutils, and gdb. over the years. I can't
claim to understand the whole of gcc, but it's not that hard to
figure out enough of one part of it when you need to do
something (I added support for --fdata-sections and
-ffunction-sections to the H8 and MSP430 targets). I'd been
using those features on ARM targets for ages, and found them to
be an indispensable way to provide encapsulation and
information-hiding without sacrificing build granularity.
> I've written a lot of embedded code for the MSP430 and other
> embedded systems, but I've never even LOOKED at the source for
> the code generator of any compiler!
Try it sometime. :)
--
Grant Edwards grante Yow! Where's SANDY DUNCAN?
at
visi.com
larwe
> > would feel comfortable hiring them for either role. Both of those
> > people are, incidentally dead.
>
> I hope that's not an occupational hazard for such people, because
> I've done both these things :-).
I believe it's an occupational hazard for every living person, so
watch out :)
David Brown
> In message <MPG.227f99fe4...@newsgroups.comcast.net>, Mark
> Borgerson <mborg...@comcast.net> writes
>> In article <GLSdnZPTPfSDQYjVnZ2dnUVZ_t3inZ2d@visi>, gra...@visi.com
>> says...
>>> Um, that's pretty much how commercial software works. If you
>>> were using mspgcc, you could just fix the problem, submit the
>>> patch, and get on with your work.
>>
>> I'm not sure that someone qualified to write good embedded
>> code for the MSP430 is also qualified to patch the code
>> generator of mspgcc.
>
> I would agree... most only think they are.
>
It depends on the level you are looking at. There are plenty of parts
of gcc which are easy to follow if you want to poke around and maybe do
some minor changes. Doing something major, like a new target port, is a
much bigger challenge, and there are parts of gcc where even veteran gcc
developers fear to tread.
Being open source does not automatically make it *practical* for
end-users to fix or enhance the code. But it makes it *possible*. That
gives you a sort of insurance policy - it might cost you time and money
to get the fixes done yourself, but you always have the option.
David Brown
Are you going to give us a clue as to what this bug is? Until you post
something more concrete, this is merely FUD. But if it is a real bug,
boil it down to some minimal test code and post the code, the compiler
options, and the generated assembly. That way we can guess if it is a
compiler bug, or a source code bug.
and...@gmail.com
> Has anyone else observed that the latest kickstart MSP430 compiler
> with optimizations=high,size?
>
> IARC/C++ Compiler for MSP430
> V4.10E/W32 [Kickstart] (4.10.5.3)
> C:\Program Files\IARSystems\Embedded Workbench 5.0\430\bin\icc430.exe
> 2/15/2008 11:03:06 AM, 15015936 bytes
>
> I have a test case that demos the problem perfectly, but it's tied to
> specific hardware. The symptom is that a pointer, if declared locally,
> is being sent off into random-land after one iteration of a loop. If
> the same declaration is moved out into global scope, or if
> optimization is turned off, the problem disappears. Target is
> MSP430F2012.
>
> I haven't yet groveled through the assembly output to see exactly what
> the difference between the two output flavors is. But this is such an
> astoundingly show-stopping bug I'm appalled it escaped.
This is not a problem that I recognize. However, I could take a look
at it, but I would need a small, stand-alone, example that
demonstrates what you think is the problem.
-- Anders Lindgren, IAR Systems, author of the MSP430 compiler
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.
Mark Borgerson
da...@westcontrol.removethisbit.com says...
More importantly, we can scan our own code to see if we have
similar cases that might need work-arounds until the problem
is resolved.
Mark Borgerson
larwe
wrote:
> Are you going to give us a clue as to what this bug is? Until you post
> something more concrete, this is merely FUD. But if it is a real bug,
I don't have the code here at work, but the gist of it is that I have
a subroutine which does something like this:
void mysub(int a, int b)
{
const unsigned char *src, *tmpsrc;
int i,j;
src = pointer_to_const_data_struct;
for (i=0;i<8;i++) {
tmpsrc = src; // BAD LINE
for (j=0;j<3;j++) {
call_another_func(*(tmpsrc++),0);
} // j-loop
src += 3;
} // i-loop
} // mysub
[the reason for doing the arithmetic this way is because the code will
have to support some more complicated cases in future - I realize
there are other ways of doing the same thing].
As shown, built in maximum speed optimization mode, the code fails.
The reason appears to be that on the second iteration through the i-
loop, the value for "src" (which was in a register) got corrupted,
probably during call_another_func(). Either of the following will fix
the problem:
- move the src declaration so it becomes a global variable, or
- turn off speed optimization
I can post the whole project somewhere if someone actually wants to
look in detail. It's going to be public domain code anyway.
ian....@gmail.com
> On Apr 27, 8:33 am, Chris H <ch...@phaedsys.org> wrote:
>
> > >the difference between the two output flavors is. But this is such an
> > >astoundingly show-stopping bug I'm appalled it escaped.
>
>
> bought version of their compiler, and found a [different] bug, the
> answer was "buy the latest upgrade".
I have found two bugs, one in each of the last two releases of their
MSP430X compiler and on each occasion I have had a new version of the
compiler sent to me with the bug fixed. These bugs then appear on the
release notes for the next version published on the web-site. Where
the problem was a code generation error then a short compilable
example together with my compiler listing was all that was required to
convince IAR that there was a problem and the corrected tools appeared
a few days later.
If the bug has been found and corrected in a more up to date version
of the tools then the answer to get a legal (as defined in the
vendor's licence agreement) copy of the newer toolset is the *right*
answer.
Ian
Chris H
<cd5e2c7a-497e-4f23...@m3g2000hsc.googlegroups.com>,
ian....@gmail.com writes
It is interesting that Lewin apparently NEVER gets this sort of service
out of any compiler or silicon company. He has ranted at me several
times when I say that the sort of help IAR have given you, as described
above, is the norm. Actually it is the norm for most of the tools
vendors.
Perhaps the problem is more with Leiwn's approach than anything else.
After al his first action on finding a bug was to publicly attack IAR
before even asking them for a response or a fix.
I note that elsewhere in this thread an IAR support person has asked
Lewin for an example code to look at. It's not because he has made a
fuss here either. It is because this is the fist time they have been
made aware of it.
and...@gmail.com
> On Apr 29, 4:04 am, David Brown <da...@westcontrol.removethisbit.com>
> wrote:
>
> > Are you going to give us a clue as to what this bug is? Until you post
> > something more concrete, this is merely FUD. But if it is a real bug,
>
> I don't have the code here at work, but the gist of it is that I have
> a subroutine which does something like this:
>
> [...]
>
> As shown, built in maximum speed optimization mode, the code fails.
> The reason appears to be that on the second iteration through the i-
> loop, the value for "src" (which was in a register) got corrupted,
> probably during call_another_func().
Thanks for the code, I managed to add some parts to the code to get it
to compile. I can confirm that you indeed found a problem in the code
generator. The cause was much more complex than you guessed, it
contained a problem with register allocation, in the presence of post-
inc:s and unrolling, where "tmpsrc" and "src" variables were placed in
the same register, which clearly is wrong.
It has been assigned bug id EW20095, and it will be fixed in the
V4.11A release which we are in the process of finishing. It will be
available relatively soon.
Thanks for finding this problem!
-- Anders Lindgren, IAR Systems
David Brown
Any chance of posting the generated assembly for this? It should not be
hard to follow, to see where the problem lies, if call_another_func is
declared extern (to avoid it being inlined by the optimiser).
Chris H
<david...@hesbynett.removethisbit.no> writes
The problem has been found see below:-
In message
<3b2e11dc-393f-4eef...@d1g2000hsg.googlegroups.com>,
"and...@gmail.com" <and...@gmail.com> writes
>Thanks for the code, I managed to add some parts to the code to get it
>to compile. I can confirm that you indeed found a problem in the code
>generator. The cause was much more complex than you guessed, it
>contained a problem with register allocation, in the presence of post-
>inc:s and unrolling, where "tmpsrc" and "src" variables were placed in
>the same register, which clearly is wrong.
>
>It has been assigned bug id EW20095, and it will be fixed in the
>V4.11A release which we are in the process of finishing. It will be
>available relatively soon.
>Thanks for finding this problem!
> -- Anders Lindgren, IAR Systems
>Disclaimer: Opinions expressed in this posting are strictly my own and
>not necessarily those of my employer.
As Anders says it is not as simple as you might think. To fix
something like this is more than a simple patch. Well the code may end
up being a simple patch but the rigorous checking and cross checking
required for side effects is substantial before you do full regression
testing.
The tests compiler companies do are quite extensive. Usually one or both
of Plum-Hall or Perennial plus several sets of in house test suites for
things like maths, assembler etc
One thing all the compiler writers I know say is the problem is not in
finding the bug but how to fix it with not putting more in. The level of
testing required afterwards is out of the reach of most programmers.
Peter Dickerson
news:3iDru1EA...@phaedsys.demon.co.uk...
So, with this level of testing how come something so serious got though the
release process? Yes, I know, these things happen and another couple of
tests are added to the validation suite.
Peter
Chris H
<firstname...@REMOVE.tesco.net> writes
Because with the number of variations and permutations both of the
language and the optimisations it is always possible to miss things. It
is interesting that "something so serious" and a "show stopping" bug has
only been found by one person.
No one else has apparently reported it yet. So clearly it is not
something everyone is doing or show stopping despite this compiler
being used by many.
Also as you can see from Anders comment it was quite complex to do with
register allocation when combined with post-incs and rollup. Not
trivial at all even if the symptom appeared to be.
> Yes, I know, these things happen and another couple of
>tests are added to the validation suite.
I knew you didn't understand. A basic OTPF Sets suite is about 70,000
tests. IAR use an industry standard test suite like this (that you
don't edit or add a couple of tests to) and FOUR other extensive test
systems they do edit. Quite apart from test compilations on a large set
of benchmark programs. Most of which are large applications not
benchmarks as such.
Compared to many other compilers IAR are very good at testing compilers
and fixing any bugs.
So in short it was not an obvious problem.
They found the cause within 24 hours of being notified
They are rolling out an update with the fix in it
Any other compiler vendors that swift to respond on eval compilers with
"no support" according to Lewin.
The problem is?
All I can see is Lewin started an unjustified rant against IAR because
he doesn't like them. Had he reported the bug to them in the first
place this would have been a non event.
We could look at the bug- fix- test- release cycle of other compilers to
compare?
I was reading about a monumental bug in the way *some* GCC compilers
handled "volatile". Now that is a show stopper.
So lets get things into perspective.
Peter Dickerson
If I were evaluating a compiler and it failed in some bad way then I'd email
the developers with example code then bin the tools or get my money back if
any had exchanged hands by then.
> No one else has apparently reported it yet. So clearly it is not something
> everyone is doing or show stopping despite this compiler being used by
> many.
You mean one person reported it here. Not the same thing.
If I can't trust the tools then that's show stopping but others may be happy
that it has an easy workaround or avoidance stratagy.
> Also as you can see from Anders comment it was quite complex to do with
> register allocation when combined with post-incs and rollup. Not trivial
> at all even if the symptom appeared to be.
I am very happy that Anders put his hand up and said t'was me. Respect for
that.
I think it was loop unrolling he mentioned. Surely register allocation and
even loop unrolling are standard bread-and-butter aspects of compilers. No
they are not trivial but they are standard fare.
Chris, you're the one who says how far behind gcc is V commercial compilers.
>> Yes, I know, these things happen and another couple of
>>tests are added to the validation suite.
>
> I knew you didn't understand. A basic OTPF Sets suite is about 70,000
> tests. IAR use an industry standard test suite like this (that you don't
> edit or add a couple of tests to) and FOUR other extensive test systems
> they do edit. Quite apart from test compilations on a large set of
> benchmark programs. Most of which are large applications not benchmarks as
> such.
No, you think you knew that I didn't understand. In fact I've have had
reason to communicate with the IAR compiler team in the past (for M16C62).
It was some time ago and the outcome after the response from them was to bin
the eval disk and avoid IAR. As I say, it was some time ago, maybe 2000, but
they had been in business long enough by then to have known better. Perhaps
now they do.
> Compared to many other compilers IAR are very good at testing compilers
> and fixing any bugs.
I would still prefer them to avoid releasing them...
> So in short it was not an obvious problem.
> They found the cause within 24 hours of being notified
> They are rolling out an update with the fix in it
Good. So they're learning.
> Any other compiler vendors that swift to respond on eval compilers with
> "no support" according to Lewin.
>
> The problem is?
>
> All I can see is Lewin started an unjustified rant against IAR because he
> doesn't like them. Had he reported the bug to them in the first place
> this would have been a non event.
Perhaps. As I said, I would have reported the bug and gone from there.
However, if others on this group are using the same compiler and
experiencing 'problems' then it might help them.
> We could look at the bug- fix- test- release cycle of other compilers to
> compare?
>
> I was reading about a monumental bug in the way *some* GCC compilers
> handled "volatile". Now that is a show stopper.
Have you got a link, because I'd certainly like to know about that. volatile
is a bit of a can of worms for any compiler because what is required for
standards conformance and what is required for customer acceptance in the
embedded field are somewhat different.
> So lets get things into perspective.
Yes, lets.
peter
sprocket
> If I were evaluating a compiler and it failed in some bad way then I'd email
> the developers with example code then bin the tools or get my money back if
> any had exchanged hands by then.
You'll end up binning them all in the end- there isn't a serious program
in the world without some bug waiting in the depths. And you won't get
your money back. Read the small print.
Peter Dickerson
Note that I said evaluating with some time limit.
Just because software ships with bugs doesn't mean we have to accept them. A
product still has to be fit for purpose.
Peter
Chris H
I am glad some one else said that. :-)
There are no compilers that are perfect. Some people are just determined
to find fault and blow it up out of all proportion.
They still find fault even after a 24 hour response (despite the fault
was not reported to IAR) on a compiler that "has no support"
Gene S. Berkowitz
says...
> In message <MPG.227ec5c2d...@news.verizon.net>, Gene S.
> Berkowitz <first...@verizon.net> writes
> >In article <JogEctNA...@phaedsys.demon.co.uk>, ch...@phaedsys.org
> >says...
> >> In message
> >> <4e894752-5193-471a...@w5g2000prd.googlegroups.com>,
> >> larwe <zwsd...@gmail.com> writes
> >> >
> >> >> >I haven't yet groveled through the assembly output to see exactly what
> >> >> >the difference between the two output flavors is. But this is such an
> >> >> >astoundingly show-stopping bug I'm appalled it escaped.
> >> >>
> >> >> What did IAR support say about it when you told them?
> >> >
> >> >Kickstart has no support.
> >>
> >> not mean you can't report bugs to the support team. Why wouldn't you?
> >>
> >> >Of course, last time I was working with a
> >> >bought version of their compiler, and found a [different] bug, the
> >> >answer was "buy the latest upgrade".
> >>
> >> support) and they had fixed the bug in a later version. It would only
> >> be "buy" a new version if you were out of support. Which you would be or
> >> you would have got the update for free.
> >>
> >> You do like trying to make mountains out of molehills.
> >>
> >> If you find a bug in ANY compiler (not just IAR) that is fixed in a
> >> newer version they tell you to get the latest version. If you are on
> >> support it is usually free. You only have to pay if it is a very old
> >> version.
> >>
> >> However if you want to use an old version that is your look out.
> >
> >Following is what the latest Kickstart version I have (came with the
> >EZ2500 kit) says when About... is clicked. Considering that practically
> >every component has a different version and build #, it's virtually
> >impossible to ever say with certainty what "version" of IAR anyone has.
>
> As with ALL compiler suites. You are either being deliberately obtuse or
> don't understand the tools. Neither trait is good for a developer.
Excuse me, but it isn't ME being obtuse, it's IAR's method of
versioning, which makes it quite difficult to document what toolchain
"version" was/should be used to build a particular "version" of an
application.
The choice is to either archive the entire IAR environment used to
produce the executable, or never/rarely "upgrade".
> The package has a release number (on the CD, zip file etc) and the
> individual components also have release numbers as you listed. It is
> called version control. Something that happens in professional software
> development.
Ooh, touchy, aren't we? Of course, it also ignores the fact that not
all "releases" of the various components work with earlier release
components of the same major version.
> I used to have this problem a lot with Keil C51 when asking what version
> of the compiler someone was using. I often got the version of the IDE.
Right, my point exactly.
--Gene
Mark Borgerson
first...@verizon.net says...
I generally choose to keep the old versions around. IAR makes it easy
to do that by allowing each new version to install in a different
directory. EWARM 5.10 takes up about 622MB of hard disk ( about 20 cents
worth of a 250GB disk). The IAR menu bar tab gives you an entry for
each installed version, so it's easy to start the appropriate version.
>
> > The package has a release number (on the CD, zip file etc) and the
> > individual components also have release numbers as you listed. It is
> > called version control. Something that happens in professional software
> > development.
>
> Ooh, touchy, aren't we? Of course, it also ignores the fact that not
> all "releases" of the various components work with earlier release
> components of the same major version.
>
> > I used to have this problem a lot with Keil C51 when asking what version
> > of the compiler someone was using. I often got the version of the IDE.
>
> Right, my point exactly.
Mark Borgerson