First I want to apologise to the group for not addressing this silly 
and infantile attack by Paul Curtis. As I said before I do not have 
the time or inclination to engage in compiler wars. 

I am not making opinionated judgements or conducting a propaganda 
war. I do not have a commercial motivation for this. I am reporting 
on impressions, attitudes and facts, under time restraints. If I have 
got a fact wrong this does not mean necessarily mean everything I 
have written is incorrect, worthless or falls part.

I will report on measurements and reliability below which will allow 
you to judge whether Code Composer for MSP430 will have chance 
of 'running well' on your PC or not. This is what I imagine most 
people are really interested in. As I stated before, I have no 
relationship or affiliation with Texas Instruments.

Manipulation of a community news group to unfairly attack a very good 
product that will be competing with the product of Curtis is not 
acceptable, nor is it acceptable for Curtis to attack anyone who 
dares not to fall into line with the group attitude that him and his 
product are Gods, Kings or Popes. Although there is something 
hilarious about self-interested commercial vendors attempting to pull 
off what appears to be offensive 'genius God' stunts on open 
community news groups.

First let me get this straight. I am NOT bagging or denigrating 
Curtis' product. It appears to be competent and well supported.  I 
conducted an evaluation of it and found it wanting with regard to 
robustness on some simple issues, which may be solvable. Since the 
product is time limited with no reduced compile size free 
compilation, unlike some competitors, I am relying on my notes to 
report real world results.

Let us also get this straight. Writing compilers and IDE has been run 
of the mill work for years. Writing compilers has been run of the 
mill work ever since UNIX command lines tools flex and bison (or lex 
and yacc). Compiler writing is a short Computer Science undergraduate 
university course, with students expected to write their own 'toy' 
compilers as short exercises.

As for writing IDEs, no informed person in his or her right mind 
would consider this work requiring 'rocket science' intellect. It is 
certainly a hell of a lot of work that requires talented people, as 
evidenced by the millions of dollars IBM has poured into Eclipse. The 
result has been fantastic.

However writing an efficient or optimising compiler is a challenge 
for accumulator CPU architectures (for example PIC) and load/store 
architecture CPU architectures (for example ARM). The MSP430 is 
neither of these. It's orthogonal GPR architecture, which allows 
instructions to be executed directly on memory addresses, makes it 
difficult to make a mess of writing an efficient compiler. In other 
words a compiler writer need to be really dumb to make a mess of 
writing a half decent compiler for the MSP430.

I have fired up the MSP430 Code Composer and confirmed I was 
incorrect to state the compiler is gcc based, however the debugger 
does come from the gcc stable. The fact that the debugger is from the 
gcc stable is very important, as this provides solid evidence to the 
attitude of industrial strength and robustness. While it may be 
straightforward to write a decent compiler for the msp430, writing a 
good debugger is another story. 

I assert the same impressions of principles and strengths underlie 
the compiler such as robustness, industrial strength and portability. 
Please note I wrote about impressions since I make no claims I am 
conducting a proper formal review.  I was also mistaken to state the 
MSP430 Code Composer runs gcc code unaltered. The way interrupt 
handlers are written is different. The usual mechanism for dealing 
with this is to use pre-processor macros to support interrupt 
handling portability between compilers.

MSP430 Composer appears to use the following software: A java virtual 
machine, Eclipse, a MSP430 compiler/linker suite, a special 
compilation of gdb (which comes from the gcc stable) and a driver for 
gdb.

Here are some results using the same PC and same MSP430 FET on a 
small MSP430 with a small amount of code


The first table documents the PC processes used with their memory 
footprints and the second table the reliability of going through a 
recompile-debug cycle.

MSP430 Developer suite        Processes in debug     Size in PC memory
-----------------------       ------------------     -----------------

IAR IDE with CSpy	      iaridepm.exe	    21 MB

Rowley's MSP430 CrossConnect  crossstudio.exe	    25 MB


TI MSP430 Code Composer	      javaaw.exe 	    46 MB
                              eclipse.exe            1 MB
(last three processes         gdb430.exe             5 MB
 terminate when not           starter.exe	   0.7 MB
 debugging)                   ti_targetserver        4 MB


Table 1: PC memory foorprint of selected MSP430 devleoper suites 
while debugging with a palallel port MSP430 FET with small MSP430 and 
small code size




MSP430 Developer suite        Recompile-Debug Steps  Reliability
-----------------------       ---------------------  -----------

IAR IDE with CSpy	      Stop Debugging	     100%
                              Edit
			      Debug

Rowley's MSP430 CrossConnect  Stop                   Inconsistent:
                              Edit                   reconnects
                              Build and Debug        required

TI MSP430 Code Composer	      terminate              100%
                              edit and save
                              debug active project


Table 2: Reliabilty of stopping debugger, editing, compiling and 
starting debugger again with MSP430 developer suites. Unable to 
restest CrossConnect


From this you can make a judgement how well MSP430 Code Composer may 
run on your PC. If you have fast PC with plenty of RAM and not too 
many programs open then MSP430 Code Composer appears to run well, but 
not as fast as the other two when going through a recompile debug 
cycle. 

These results are for low code sizes. Larger code sizes may narrow 
differences as process start up times become less relvant for Code 
Composer.

On less and less powerful PCs Code Composer will start to 'choke' and 
give a poor impression of itself before the other two suites. IAR 
should be the last to 'die' on PCs with decreasing power.

The results do not take into account the 'start and finish' compile, 
link and code translation processes that take place befoe loading of 
executable code.

In a real world code production environment having tools that are 
reliable and consistent is a very important productivity issue.

I have left Curtis' entire repsonse intact below. It is clear he is 
acting in the capacity of a vendor and it is clear he has made no 
effort to provide objective data to address the real issues of 
interest and concern to the community.


John Heenan


--- In msp430@msp4..., "Paul Curtis" <plc@r...> wrote:
> John,
> 
> > I am not going to check and confirm if the MSP430 Code 
> > Composer compiler is plugged into the gcc infrastructure or 
> > not.
> 
> Shame, it means your opinion isn't worth much because you made an
> assertion without checking your facts and you still can't be 
bothered to
> check them.
> 
> > I suspect this is largely irrelevant as I am suspect the 
> > same highly regarded principles and standards apply whether 
> > the compiler comes under the gcc stable or not.
> 
> That was not the tone of your original post.  You decided that CCE 
was
> industrial strength as it was based on Eclipse and
GCC and a command
> line debugger.  Only the fact it's based on Eclipse is true.
> 
> My only issue is the misrepresentation of CCE for what it is not.  
It is
> not based on GCC and it is not "open
source".  TI's announcement
> stretches the truth in my estimation.  Whether it floats customer's
> collective boats is immaterial until it gets kicked out the door.
> 
> > In fact you need to a very dumb compiler writer to make a 
> > mess of writing an efficient complier for the MSP430 due to 
> > the nature of the addressing architecture of the MSP430. The 
> > ease of writing compilers for the MSP430 may explain why 
> > there are so many compilers on offer for the MSP430...
> 
> The reason there are so many has nothing to do with architecture
> design--it's all to do with the fact the MSP430 is storming the 
market.
> In fact, you need to be a pretty bright compiler
engineer to make 
the
> most of the MSP430 as benchmarks will show.
Producing a compiler is 
less
> than half the story--you need a debugger and
support and libraries 
and
> documentation and list list goes on.
> 
> You just can't make statements like that and not have them 
challenged.
> 
> --
> Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors

The tables I contributed have spaces stipped when viewed directly on 
the newsgroup through a web browser. 

Here they are again with stripped spaces replaced. It should also be 
noted that table 1 does not indicate the size of processses running 
at the kernel level.

The first table documents the PC processes used with their memory 
footprints and the second table the reliability of going through a 
recompile-debug cycle.

MSP430 Developer suite ------- Processes in debug -- Size in PC memory
---------------------- ------ ------------------ --  -----------------

IAR IDE with CSpy ------------ iaridepm.exe -------- 21 MB

Rowley's MSP430 CrossConnect - crossstudio.exe ----- 25 MB


TI MSP430 Code Composer ------ javaaw.exe ---------- 46 MB
------------------------------ eclipse.exe ---------- 1 MB
- (last three processes ------ gdb430.exe ----------- 5 MB
- terminate when not --------- starter.exe -------- 0.7 MB
- debugging) ----------------- ti_targetserver ------ 4 MB


Table 1: PC memory foorprint of selected MSP430 devleoper suites 
while debugging with a palallel port MSP430 FET with small MSP430 and 
small code size


MSP430 Developer suite ------- Recompile-Debug Steps - Reliability
----------------------- ------ --------------------- - -----------

IAR IDE with CSpy ------------ Stop Debugging -------- 100%
------------------------------ Edit
------------------------------ Debug

Rowley's MSP430 CrossConnect - Stop ------------------ Inconsistent:
------------------------------ Edit ------------------ reconnects
------------------------------ Build and Debug ------- required

TI MSP430 Code Composer ------ terminate ------------- 100%
------------------------------ edit and save
------------------------------ debug active project


Table 2: Reliabilty of stopping debugger, editing, compiling and 
starting debugger again with MSP430 developer suites. Unable to 
restest CrossConnect

John Heenan


--- In msp430@msp4..., "John Heenan" <l10@a...> wrote:
> 
> First I want to apologise to the group for not addressing this 
silly 
> and infantile attack by Paul Curtis. As I said
before I do not have 
> the time or inclination to engage in compiler wars. 
> 
> I am not making opinionated judgements or conducting a propaganda 
> war. I do not have a commercial motivation for this. I am reporting 
> on impressions, attitudes and facts, under time restraints. If I 
have 
> got a fact wrong this does not mean necessarily
mean everything I 
> have written is incorrect, worthless or falls part.
> 
> I will report on measurements and reliability below which will 
allow 
> you to judge whether Code Composer for MSP430 will
have chance 
> of 'running well' on your PC or not. This is what I imagine most 
> people are really interested in. As I stated before, I have no 
> relationship or affiliation with Texas Instruments.
> 
> Manipulation of a community news group to unfairly attack a very 
good 
> product that will be competing with the product of
Curtis is not 
> acceptable, nor is it acceptable for Curtis to attack anyone who 
> dares not to fall into line with the group attitude that him and 
his 
> product are Gods, Kings or Popes. Although there
is something 
> hilarious about self-interested commercial vendors attempting to 
pull 
> off what appears to be offensive 'genius
God' stunts on open 
> community news groups.
> 
> First let me get this straight. I am NOT bagging or denigrating 
> Curtis' product. It appears to be competent and well supported.  I 
> conducted an evaluation of it and found it wanting with regard to 
> robustness on some simple issues, which may be solvable. Since the 
> product is time limited with no reduced compile size free 
> compilation, unlike some competitors, I am relying on my notes to 
> report real world results.
> 
> Let us also get this straight. Writing compilers and IDE has been 
run 
> of the mill work for years. Writing compilers has
been run of the 
> mill work ever since UNIX command lines tools flex and bison (or 
lex 
> and yacc). Compiler writing is a short Computer
Science 
undergraduate 
> university course, with students expected to write
their own 'toy' 
> compilers as short exercises.
> 
> As for writing IDEs, no informed person in his or her right mind 
> would consider this work requiring 'rocket science' intellect. It

is 
> certainly a hell of a lot of work that requires
talented people, as 
> evidenced by the millions of dollars IBM has poured into Eclipse. 
The 
> result has been fantastic.
> 
> However writing an efficient or optimising compiler is a challenge 
> for accumulator CPU architectures (for example PIC) and load/store 
> architecture CPU architectures (for example ARM). The MSP430 is 
> neither of these. It's orthogonal GPR architecture, which allows 
> instructions to be executed directly on memory addresses, makes it 
> difficult to make a mess of writing an efficient compiler. In other 
> words a compiler writer need to be really dumb to make a mess of 
> writing a half decent compiler for the MSP430.
> 
> I have fired up the MSP430 Code Composer and confirmed I was 
> incorrect to state the compiler is gcc based, however the debugger 
> does come from the gcc stable. The fact that the debugger is from 
the 
> gcc stable is very important, as this provides
solid evidence to 
the 
> attitude of industrial strength and robustness.
While it may be 
> straightforward to write a decent compiler for the msp430, writing 
a 
> good debugger is another story. 
> 
> I assert the same impressions of principles and strengths underlie 
> the compiler such as robustness, industrial strength and 
portability. 
> Please note I wrote about impressions since I make
no claims I am 
> conducting a proper formal review.  I was also mistaken to state 
the 
> MSP430 Code Composer runs gcc code unaltered. The
way interrupt 
> handlers are written is different. The usual mechanism for dealing 
> with this is to use pre-processor macros to support interrupt 
> handling portability between compilers.
> 
> MSP430 Composer appears to use the following software: A java 
virtual 
> machine, Eclipse, a MSP430 compiler/linker suite,
a special 
> compilation of gdb (which comes from the gcc stable) and a driver 
for 
> gdb.
> 
> Here are some results using the same PC and same MSP430 FET on a 
> small MSP430 with a small amount of code
> 
> 
> The first table documents the PC processes used with their memory 
> footprints and the second table the reliability of going through a 
> recompile-debug cycle.
> 
> MSP430 Developer suite        Processes in debug     Size in PC 
memory
> -----------------------       ------------------  
  ---------------
--
> 
> IAR IDE with CSpy	      iaridepm.exe	    21 MB
> 
> Rowley's MSP430 CrossConnect  crossstudio.exe	    25 MB
> 
> 
> TI MSP430 Code Composer	      javaaw.exe 	    46 MB
>                               eclipse.exe            1 MB
> (last three processes         gdb430.exe             5 MB
>  terminate when not           starter.exe	   0.7 MB
>  debugging)                   ti_targetserver        4 MB
> 
> 
> Table 1: PC memory foorprint of selected MSP430 devleoper suites 
> while debugging with a palallel port MSP430 FET with small MSP430 
and 
> small code size
> 
> 
> 
> 
> MSP430 Developer suite        Recompile-Debug Steps  Reliability
> -----------------------       ---------------------  -----------
> 
> IAR IDE with CSpy	      Stop Debugging	     100%
>                               Edit
> 			      Debug
> 
> Rowley's MSP430 CrossConnect  Stop                   Inconsistent:
>                               Edit                   reconnects
>                               Build and Debug        required
> 
> TI MSP430 Code Composer	      terminate              100%
>                               edit and save
>                               debug active project
> 
> 
> Table 2: Reliabilty of stopping debugger, editing, compiling and 
> starting debugger again with MSP430 developer suites. Unable to 
> restest CrossConnect
> 
> 
> From this you can make a judgement how well MSP430 Code Composer 
may 
> run on your PC. If you have fast PC with plenty of
RAM and not too 
> many programs open then MSP430 Code Composer appears to run well, 
but 
> not as fast as the other two when going through a
recompile debug 
> cycle. 
> 
> These results are for low code sizes. Larger code sizes may narrow 
> differences as process start up times become less relvant for Code 
> Composer.
> 
> On less and less powerful PCs Code Composer will start to 'choke'

and 
> give a poor impression of itself before the other
two suites. IAR 
> should be the last to 'die' on PCs with decreasing power.
> 
> The results do not take into account the 'start and finish' 
compile, 
> link and code translation processes that take
place befoe loading 
of 
> executable code.
> 
> In a real world code production environment having tools that are 
> reliable and consistent is a very important productivity issue.
> 
> I have left Curtis' entire repsonse intact below. It is clear he is 
> acting in the capacity of a vendor and it is clear he has made no 
> effort to provide objective data to address the real issues of 
> interest and concern to the community.
> 
> 
> John Heenan
> 
> 
> --- In msp430@msp4..., "Paul Curtis" <plc@r...> wrote:
> > John,
> > 
> > > I am not going to check and confirm if the MSP430 Code 
> > > Composer compiler is plugged into the gcc infrastructure or 
> > > not.
> > 
> > Shame, it means your opinion isn't worth much because you made an
> > assertion without checking your facts and you still can't be 
> bothered to
> > check them.
> > 
> > > I suspect this is largely irrelevant as I am suspect the 
> > > same highly regarded principles and standards apply whether 
> > > the compiler comes under the gcc stable or not.
> > 
> > That was not the tone of your original post.  You decided that 
CCE 
> was
> > industrial strength as it was based on Eclipse and GCC and a 
command
> > line debugger.  Only the fact it's based
on Eclipse is true.
> > 
> > My only issue is the misrepresentation of CCE for what it is 
not.  
> It is
> > not based on GCC and it is not "open source".  TI's
announcement
> > stretches the truth in my estimation.  Whether it floats 
customer's
> > collective boats is immaterial until it gets
kicked out the door.
> > 
> > > In fact you need to a very dumb compiler writer to make a 
> > > mess of writing an efficient complier for the MSP430 due to 
> > > the nature of the addressing architecture of the MSP430. The 
> > > ease of writing compilers for the MSP430 may explain why 
> > > there are so many compilers on offer for the MSP430...
> > 
> > The reason there are so many has nothing to do with architecture
> > design--it's all to do with the fact the MSP430 is storming the 
> market.
> > In fact, you need to be a pretty bright compiler engineer to make 
> the
> > most of the MSP430 as benchmarks will show. Producing a compiler 
is 
> less
> > than half the story--you need a debugger and support and 
libraries 
> and
> > documentation and list list goes on.
> > 
> > You just can't make statements like that and not have them 
> challenged.
> > 
> > --
> > Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> > CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors

John Heenan wrote:

>First I want to apologise to the group for not
addressing this silly 
>and infantile attack by Paul Curtis. As I said before I do not have 
>the time or inclination to engage in compiler wars. 
>
I hadn't noticed, has something been going on here?

>I will report on measurements and reliability below
which will allow 
>you to judge whether Code Composer for MSP430 will have chance 
>of 'running well' on your PC or not. This is what I imagine most 
>people are really interested in. As I stated before, I have no 
>relationship or affiliation with Texas Instruments.
>
>Manipulation of a community news group to unfairly attack a very good 
>product that will be competing with the product of Curtis is not 
>acceptable, nor is it acceptable for Curtis to attack anyone who 
>dares not to fall into line with the group attitude that him and his 
>product are Gods, Kings or Popes. Although there is something 
>hilarious about self-interested commercial vendors attempting to pull 
>off what appears to be offensive 'genius God' stunts on open 
>community news groups.
>
Bruce is GOD, as illustrated by the Monty Python films, the film Bruce 
Almighty and his founding of this group. Paul was merely an Apostle, a 
follower, who happened to have a few big buildings named after him. I'm 
Judas, I don't like compilers. Paul doesn't claim to be a genius, only
I 
do indirectly, he did have a few Popes named after him though, which I 
didn't. I don't know how a product can be God, King or Pope.

>First let me get this straight. I am NOT bagging or
denigrating 
>Curtis' product.
>
Well you are, if you're going to do so admit it, you have a right to
do 
so here. just don't contradict yourself or be hypocritical.

> It appears to be competent and well supported.  I 
>conducted an evaluation of it and found it wanting with regard to 
>robustness on some simple issues, which may be solvable. Since the 
>product is time limited with no reduced compile size free 
>compilation, unlike some competitors, I am relying on my notes to 
>report real world results.
>
Well the vast majority of users here seem to feel that 4k limit
can't 
possibly give you a true feel for a compiler in a real world 
application, whereas unlimited 30 day trials are fair. I feel the same 
way. It's no good having a 4k limit if I want to evaluate the hardware 
and the compiler for a design that requires 20k.

>
>Let us also get this straight. Writing compilers and IDE has been run 
>of the mill work for years. Writing compilers has been run of the 
>mill work ever since UNIX command lines tools flex and bison (or lex 
>and yacc). Compiler writing is a short Computer Science undergraduate 
>university course, with students expected to write their own 'toy'

>compilers as short exercises.
>
>As for writing IDEs, no informed person in his or her right mind 
>would consider this work requiring 'rocket science' intellect. It
is 
>certainly a hell of a lot of work that requires talented people, as 
>evidenced by the millions of dollars IBM has poured into Eclipse. The 
>result has been fantastic.
>
Glad you appreciate the bloated piece of crap. Personally its a dog that 
doesn't deserve a kennel in my opinion. An IDE should be simple, 
functional and intuitive, it is, after all,simply another user interface 
device. Eclipse is none of these. You should be able to pick up a well 
designed product and, having a smattering of knowledge of its purpose, 
be able to use it without reference to a manual. That is one element of 
good design.You also should shy away from contradictions. Rocket Science 
takes millions, writing an IDE shouldn't, and probably didn't in the 
case of most IDE's, why then did IBM have to plough so much into it? 
Most cheap IDEs are reasonably functional. Even IARs IDE is better than 
Eclipse, ctually oit's more c-Spy that gets to me, the IDE, though not a 
world shaker, is tolerably usable.

>
>However writing an efficient or optimising compiler is a challenge 
>for accumulator CPU architectures (for example PIC) and load/store 
>architecture CPU architectures (for example ARM). The MSP430 is 
>neither of these. It's orthogonal GPR architecture, which allows 
>instructions to be executed directly on memory addresses, makes it 
>difficult to make a mess of writing an efficient compiler. In other 
>words a compiler writer need to be really dumb to make a mess of 
>writing a half decent compiler for the MSP430.
>
Obviously you haven't studied the MSP430 architecture very much.
there 
is a world of difference between writing a competent compiler and 
writing a first rate optimising compiler. register allocation, 
instruction ordering, bit allocation, use of constant generators, 
word/byte interoperability are all the little things that are the real 
tricks to making the MSP430 perform.

>MSP430 Developer suite        Recompile-Debug Steps
 Reliability
>-----------------------       ---------------------  -----------
>
>IAR IDE with CSpy	      Stop Debugging	     100%
>                              Edit
>			      Debug
>
>Rowley's MSP430 CrossConnect  Stop                   Inconsistent:
>                              Edit                   reconnects
>                              Build and Debug        required
>
>TI MSP430 Code Composer	      terminate              100%
>                              edit and save
>                              debug active project
>
>
>Table 2: Reliabilty of stopping debugger, editing, compiling and 
>starting debugger again with MSP430 developer suites. Unable to 
>restest CrossConnect
>  
>
Well I reckon that I know the IAR tools better than anybody here, as 
I've probably had them longer. Hell I even have the original serial port 
IAR JTAG interface. Even now C-Spy is not a stable debug platform, it is 
my biggest gripe against it, and I use assembler. It should be rock 
solid. It crashes, often requiring the entire PC to be reset. I'm not 
the only one here who has troubles, so either you have a custom version 
of IAR or you haven't pushed it at all.

I have no axes to grind regarding compilers, nor Paul. Who i only know 
through this group. If he fancies rising to this bait he's big enough 
and ugly enough to do so himself (I know, I've seen his photograph), but 
i do get pissed off by these occasional diatribes from fairly new 
posters. Looking at the inclusions I  read it very clearly, you've 
posted a harangue of Crossworks, Pauls naturally defended his product, 
especially where you seem to have no foundation for your claims, and 
appears to have been fairly polite about the whole thing. You've posted 
statements without bothering to check them, then refused to check saying 
you don't need to, then make such absurd satements as "since the 
debugger is gcc based I assert the rest of it is as good quality". 
That's is too much bullshit. You posted some assumptions that were 
wrong. and are compounding it with further assumptions. Post facts or 
don't get into arguments.

cheers

Al

At 10:37 AM 4/17/2005, you wrote:
>...
>Bruce is GOD, as illustrated by the Monty Python films, the film Bruce
>Almighty and his founding of this group. Paul was merely an Apostle, a
>follower, who happened to have a few big buildings named after him. I'm
>Judas, I don't like compilers. Paul doesn't claim to be a genius,
only I
>do indirectly, he did have a few Popes named after him though, which I
>didn't. I don't know how a product can be God, King or Pope.

Hmm... there's no Al the Pope? Is it too late for you to run?

:-) ONLY kidding....


// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com) 

My running days are long over, now it's a slow, drunken, duck like 
waddle on those days I'm mobile. :-D  

Anyway I never saw the last Pope running anywhere, it's too damned 
undignified. (probably not as undignified as duck imitations, but what 
the hell!).

I just realised, Judas's surname wasn't iscariot, the gospels were 
written later, and somebody managed to smudge the ink somewhere along 
the line. I always wondered how they all got around the country so 
damned much, now I understand. Somebody wrote

          judas iscariot

What they really should have written was

          judas's car lot

He was a used car salesman, no wonder you couldn't trust the bugger.

Al

Richard wrote:

>At 10:37 AM 4/17/2005, you wrote:
>  
>
>>...
>>Bruce is GOD, as illustrated by the Monty Python films, the film Bruce
>>Almighty and his founding of this group. Paul was merely an Apostle, a
>>follower, who happened to have a few big buildings named after him.
I'm
>>Judas, I don't like compilers. Paul doesn't claim to be a
genius, only I
>>do indirectly, he did have a few Popes named after him though, which I
>>didn't. I don't know how a product can be God, King or Pope.
>>    
>>
>
>Hmm... there's no Al the Pope? Is it too late for you to run?
>
>:-) ONLY kidding....
>
>
>// richard (This email is for mailing lists. To reach me directly, please 
>use richard at imagecraft.com) 
>
>  
>

Well, let me jump in here. It's true that writing a
"compiler" is an 
undergraduate course, but making a business selling production quality 
compilers is not easy. It's like saying writing word processor is easy. 
Well it is, but look at where Wordstar, Word Perfect, and a gazillion other 
word processor companies went. I am not saying that one has to act like 
Microsoft to dominate the market (god forbids if that's the case), but if 
you think running a software company that happens to sell compilers is as 
easy as writing a compiler....

This may or may not have any bearings with what you are saying WRT Paul, 
but thought I will throw in my 2 cents...

At 09:38 AM 4/17/2005, John Heenan wrote:
>....
>Let us also get this straight. Writing compilers and IDE has been run
>of the mill work for years. Writing compilers has been run of the
>mill work ever since UNIX command lines tools flex and bison (or lex
>and yacc). Compiler writing is a short Computer Science undergraduate
>university course, with students expected to write their own 'toy'
>compilers as short exercises.
>
>As for writing IDEs, no informed person in his or her right mind
>would consider this work requiring 'rocket science' intellect. It
is
>certainly a hell of a lot of work that requires talented people, as
>evidenced by the millions of dollars IBM has poured into Eclipse. The
>result has been fantastic.
>
>However writing an efficient or optimising compiler is a challenge
>for accumulator CPU architectures (for example PIC) and load/store
>architecture CPU architectures (for example ARM). The MSP430 is
>neither of these. It's orthogonal GPR architecture, which allows
>instructions to be executed directly on memory addresses, makes it
>difficult to make a mess of writing an efficient compiler. In other
>words a compiler writer need to be really dumb to make a mess of
>writing a half decent compiler for the MSP430.
>...
>

// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com) 

What is your problem Al?

I post real world useful and specific results and get to the point 
and you respond with a silly and unbalanced opiniated diatribe 
against me. Hardly does you any credit for your claim of 'indirect 
genius', whatever that is supposed to mean.

I don't have time for this. 

John Heenan


--- In msp430@msp4..., Onestone <onestone@b...> wrote:
> John Heenan wrote:
> 
> >First I want to apologise to the group for not addressing this 
silly 
> >and infantile attack by Paul Curtis. As I said
before I do not 
have 
> >the time or inclination to engage in compiler
wars. 
> >
> I hadn't noticed, has something been going on here?
> 
> >I will report on measurements and reliability below which will 
allow 
> >you to judge whether Code Composer for MSP430
will have chance 
> >of 'running well' on your PC or not. This is what I imagine
most 
> >people are really interested in. As I stated before, I have no 
> >relationship or affiliation with Texas Instruments.
> >
> >Manipulation of a community news group to unfairly attack a very 
good 
> >product that will be competing with the
product of Curtis is not 
> >acceptable, nor is it acceptable for Curtis to attack anyone who 
> >dares not to fall into line with the group attitude that him and 
his 
> >product are Gods, Kings or Popes. Although
there is something 
> >hilarious about self-interested commercial vendors attempting to 
pull 
> >off what appears to be offensive 'genius
God' stunts on open 
> >community news groups.
> >
> Bruce is GOD, as illustrated by the Monty Python films, the film 
Bruce 
> Almighty and his founding of this group. Paul was
merely an 
Apostle, a 
> follower, who happened to have a few big buildings
named after him. 
I'm 
> Judas, I don't like compilers. Paul
doesn't claim to be a genius, 
only I 
> do indirectly, he did have a few Popes named after
him though, 
which I 
> didn't. I don't know how a product can
be God, King or Pope.
> 
> >First let me get this straight. I am NOT bagging or denigrating 
> >Curtis' product.
> >
> Well you are, if you're going to do so admit it, you have a right 
to do 
> so here. just don't contradict yourself or be
hypocritical.
> 
> > It appears to be competent and well supported.  I 
> >conducted an evaluation of it and found it wanting with regard to 
> >robustness on some simple issues, which may be solvable. Since the 
> >product is time limited with no reduced compile size free 
> >compilation, unlike some competitors, I am relying on my notes to 
> >report real world results.
> >
> Well the vast majority of users here seem to feel that 4k limit 
can't 
> possibly give you a true feel for a compiler in a
real world 
> application, whereas unlimited 30 day trials are fair. I feel the 
same 
> way. It's no good having a 4k limit if I want
to evaluate the 
hardware 
> and the compiler for a design that requires 20k.
> 
> >
> >Let us also get this straight. Writing compilers and IDE has been 
run 
> >of the mill work for years. Writing compilers
has been run of the 
> >mill work ever since UNIX command lines tools flex and bison (or 
lex 
> >and yacc). Compiler writing is a short
Computer Science 
undergraduate 
> >university course, with students expected to
write their own 'toy' 
> >compilers as short exercises.
> >
> >As for writing IDEs, no informed person in his or her right mind 
> >would consider this work requiring 'rocket science'
intellect. It 
is 
> >certainly a hell of a lot of work that
requires talented people, 
as 
> >evidenced by the millions of dollars IBM has
poured into Eclipse. 
The 
> >result has been fantastic.
> >
> Glad you appreciate the bloated piece of crap. Personally its a dog 
that 
> doesn't deserve a kennel in my opinion. An
IDE should be simple, 
> functional and intuitive, it is, after all,simply another user 
interface 
> device. Eclipse is none of these. You should be
able to pick up a 
well 
> designed product and, having a smattering of
knowledge of its 
purpose, 
> be able to use it without reference to a manual.
That is one 
element of 
> good design.You also should shy away from
contradictions. Rocket 
Science 
> takes millions, writing an IDE shouldn't, and
probably didn't in 
the 
> case of most IDE's, why then did IBM have to
plough so much into 
it? 
> Most cheap IDEs are reasonably functional. Even
IARs IDE is better 
than 
> Eclipse, ctually oit's more c-Spy that gets
to me, the IDE, though 
not a 
> world shaker, is tolerably usable.
> 
> >
> >However writing an efficient or optimising compiler is a challenge 
> >for accumulator CPU architectures (for example PIC) and load/store 
> >architecture CPU architectures (for example ARM). The MSP430 is 
> >neither of these. It's orthogonal GPR architecture, which allows 
> >instructions to be executed directly on memory addresses, makes it 
> >difficult to make a mess of writing an efficient compiler. In 
other 
> >words a compiler writer need to be really dumb
to make a mess of 
> >writing a half decent compiler for the MSP430.
> >
> Obviously you haven't studied the MSP430 architecture very much. 
there 
> is a world of difference between writing a
competent compiler and 
> writing a first rate optimising compiler. register allocation, 
> instruction ordering, bit allocation, use of constant generators, 
> word/byte interoperability are all the little things that are the 
real 
> tricks to making the MSP430 perform.
> 
> >MSP430 Developer suite        Recompile-Debug Steps  Reliability
> >-----------------------       ---------------------  -----------
> >
> >IAR IDE with CSpy	      Stop Debugging	     100%
> >                              Edit
> >			      Debug
> >
> >Rowley's MSP430 CrossConnect  Stop                   Inconsistent:
> >                              Edit                   reconnects
> >                              Build and Debug        required
> >
> >TI MSP430 Code Composer	      terminate              100%
> >                              edit and save
> >                              debug active project
> >
> >
> >Table 2: Reliabilty of stopping debugger, editing, compiling and 
> >starting debugger again with MSP430 developer suites. Unable to 
> >restest CrossConnect
> >  
> >
> Well I reckon that I know the IAR tools better than anybody here, 
as 
> I've probably had them longer. Hell I even
have the original serial 
port 
> IAR JTAG interface. Even now C-Spy is not a stable
debug platform, 
it is 
> my biggest gripe against it, and I use assembler.
It should be rock 
> solid. It crashes, often requiring the entire PC to be reset. I'm 
not 
> the only one here who has troubles, so either you
have a custom 
version 
> of IAR or you haven't pushed it at all.
> 
> I have no axes to grind regarding compilers, nor Paul. Who i only 
know 
> through this group. If he fancies rising to this
bait he's big 
enough 
> and ugly enough to do so himself (I know,
I've seen his 
photograph), but 
> i do get pissed off by these occasional diatribes
from fairly new 
> posters. Looking at the inclusions I  read it very clearly, you've 
> posted a harangue of Crossworks, Pauls naturally defended his 
product, 
> especially where you seem to have no foundation
for your claims, 
and 
> appears to have been fairly polite about the whole
thing. You've 
posted 
> statements without bothering to check them, then
refused to check 
saying 
> you don't need to, then make such absurd
satements as "since the 
> debugger is gcc based I assert the rest of it is as good quality". 
> That's is too much bullshit. You posted some assumptions that were 
> wrong. and are compounding it with further assumptions. Post facts 
or 
> don't get into arguments.
> 
> cheers
> 
> Al

John Heenan wrote:

>What is your problem Al?
>
>I post real world useful and specific results
>
No! Much of what you posted was opinionated supposition, hence my like 
reply. To rabbit on about religion etc takes your post beyond serious 
consideration. You openly admitted errors regarding earlier statements, 
then go on to say. I have no problems. I'm not the one who went 
ballistic and started slinging insults at another group member. I saw 
nothing agressive or off the wall in the reponses you posted from Paul, 
and, frankly I'm pissed off at your suggestions that this group is a 
bunch of sychophants, I responded in the vein that such comment deserved.

"I have fired up the MSP430 Code Composer and confirmed I was 
incorrect to state the compiler is gcc based, however the debugger 
does come from the gcc stable. The fact that the debugger is from the 
gcc stable is very important, as this provides solid evidence to the 
attitude of industrial strength and robustness."

followed by:-

"I assert the same impressions of principles and strengths underlie 
the compiler such as robustness, industrial strength and portability."

The first boils down to. "I was wrong about the compiler". The second 
says "but I assume it is of the same quality etc as the debugger". 
Nothing useful or specific in there, just personal opinion, and 
guesswork masquerading as fact.

> and get to the point 
>and you respond with a silly and unbalanced opiniated diatribe 
>against me. 
>
Maybe unbalanced, certainly opinionated, after all without an opinion 
why bother posting. And I fail to see what point you actually got to. 
Look over the history of posts in this group and you will see that your 
100% C-Spy reliability, the main thing I disputed, does not match the 
findings of a lot of members here, therefore your testing was 
inadequate. If that test was inadequate, and failed to show up C-Spys 
shortcomings (and everything has them, making any 100% result 
suspicious) and it was the same test applied to your other 'facts'
then 
they too must be suspect. Yes it was opinionated. My opinion is that you 
are trying to pass off personal bias as hard fact. The evidence supports 
it. Motive? who knows? Perhaps you got caught with your knickers down 
making a few wrong statements and, rather than backing off gracefully, 
got embroiled in an indefensible position.

>Hardly does you any credit for your claim of
'indirect 
>genius', whatever that is supposed to mean.
>
A private joke

>
>I don't have time for this. 
>
I do.

Al

>  
>

John,

> First I want to apologise to the group for not
addressing this silly 
> and infantile attack by Paul Curtis. As I said before I do not have 
> the time or inclination to engage in compiler wars. 

Infantile attack?  John, you've completely lost the plot here.

-- Paul.

John,

> Rowley's MSP430 CrossConnect -
crossstudio.exe ----- 25 MB

You can't even bother to get the name of the toolset right.  Gee, it is
that hard?  I mean, it's on the front page of our website for heaven's
sake and all through our documentation.  Should I point out that VS.NET
runs at 50MB on my machine?  But hell, I don't care, I have 1GB of RAM.

> Table 2: Reliabilty of stopping debugger, editing,
compiling and 
> starting debugger again with MSP430 developer suites. Unable to 
> restest CrossConnect

We haven't supplied you with a CrossConnect...

-- Paul.