Hi Jon,

I'll make this brief... 

> >My organic optimizer is
> >much better than my programmed one, as the programmed one was given 
> >birth by the organic one.
> 
> Well, that doesn't mean it can't do darned well, Paul.  As I 
> said, I've actually encountered a compiler (not C, but 
> Pascal) that was incredible at optimization.
> Time after time I found it to arrange things almost as I 
> would.  Only once, though.  But it tells me it *can* be done.
> 
> >I'd pit my wetware against any binary machine to produce 
> better code, 
> >but in a much longer timeframe--a 3GHz Pentium can analyse 
> things much 
> >faster than I can sequentially, but I have parallelism and 
> insight on 
> >my side.
> 
> If.. Paul... If you implement the optimizations.

Have you got the wrong end of the stick here, Jon?  My organic optimizer
is truly portable--it travels about 5'5" off the ground and is encased
in a ballistic container at all times.  I'd be lost without it, it's
so
precious.  Got it yet?  ;-)

Perhaps you've fallen into the trap of thinking my organic optimizer is
something other than I do.

-- Paul.

Jon, 

> Because embedded C compiler writers are more busy
writing 
> fancy IDEs and libraries and wizards and who knows what else.

Well, I've refrained from that.  However, to sell a product these days
you need the eye candy, or else you'll just die as an outfit.

> I just think the embedded compilers could be
SOOOOO much 
> better.  I think I have an idea just how smart you compiler 
> writers really are (fantastic, as a guiding rule, I think) 
> and that I, as an embedded compiler user, shouldn't have to 
> go begging for something as relatively basic as structure 
> disaggregation.  And that's only one of so many things.  Yes, 
> it's work to implement.  But I can think of lots worse things 
> to waste your time on (like playing nanny in hoisting novice 
> C compiler writers with wizard tools and pretty colors.)

Actually, breaking a structure memberwise is not as simple as it sounds.
It can be done, but there are better ways to spend development resources
than do this, IMNSHO.

> Of course, that's merely my lay opinion.  So
I'll defer to 
> your superior, professional knowledge on these points.

It's just a biz decision.  I could contemplate optimizations until I
have little breath left, but my life isn't measured by what I do or do
not put into a compiler, thankfully.  Given the choice of adding more
optimizations to an existing product or writing a new CG for another
processor, I'd go for the new processor every darned time because
there's no feeling quite as good as running your first compiled program
on a machine using your own tools.

-- Paul.

On Sun, 08 Aug 2004 12:50:58 -0700, Richard wrote:

>Jonathan, as usual, you make good arguments, but
you miss the point - the 
>problem is not technical, but business.

Absolutely.  I haven't missed this point and you are exactly right to bring
this
up.  I've also given lip-service to this point, as well.

Of course, I just don't have to like it.  The class of buyers I fit into
isn't a
very big one from a compiler writer's point of view.

>Sure, I know how to do structure 
>disaggregation, and tons of other stuff, but at what cost? How many 
>compilers do we have to sell to recoup that cost?

You do have to be practical, don't you?

Hehe.  Of course I take your point, here.

But compiler writers should not play into those believing C compiler canards,
either.

>I would even be more blunt - there are 4 or 5 good
compilers for MSP430 out 
>there. How big do you think the market is?

I've no idea and, actually, I'd be interested in knowing.  Can you
share this?

But it doesn't need to be big, Richard, to support one's own family. 
600 copies
a year at US$200 is US$120k.  Enough to get by and at 50 copies a month or about
2 a day.  And what a business!!!

Of course, you have my unvarnished respect, too.

My reason for commenting was Paul's:

>>> I'm not arguing that an organic
optimizer is much better than any
>>> programmed optimizer--it's a given, if there is sufficient
time and
>>> inclination for the human brain.  For some systems, the MSP430 and
>>> assembler are a perfect fit.  For some application domains, they
are
>>> non-starters.  Who would seriously code an application for Windows
>>> completely in x86 assembler nowadays?

The example of "*complete* Windows applications" is a diametrical
extreme, at
the further reaches of the imagination, and it does NOT make the point.  It
sounds "reasonable," because "we all know" that completely
coding up a modern
Windows application (and Windows applications today must climb over very high
'vertical' barriers to be viable) in assembly would be "crazy
minded."

But it's arguing from extremes and I needed to point this out.  More, Paul
chose
to compound this abuse of rhetoric by using the "Well, of course humans can
be
better given enough time and sweat."  Yet another point made by taking an
extreme to then cast the "light of reasonableness" on what was said. 
But it
also implies, by reverse logic, that without this extreme of time available that
humans just maybe can't do so well.  And that just isn't true.  I can
routinely
write excellent assembly code on short schedules in roughly the same time
I'd
take with C.  I might admit that it takes me a little longer in assembly, if
pressed, but regarding the overall project schedule it is rarely a determining
consideration, or even much a factor.  The reasoning for using C falls along
other lines, for me.

Where Paul was right in the above was in his "for some systems, the MSP430
and
assembler are a perfect fit."  But that was buried between the rest.  And
the
rest made the implication that programmers who actually might *reasonably*
choose to write in assembler, obviously aren't really doing sophisticated
applications.  And this is wrong.

A point that Al took to task, well and rightly.

>Do you think any of us is 
>sipping Margarita on a tropical island?

Hehe!!  If you were, I'd go find you and join you!

>Certain 3 letter company is the 2 
>hundred pounds gorilla in the embedded compiler business. You know, the one 
>that claims they generate the best code with the best optimizations etc. 
>Have you checked their Financial Report lately? They are not rolling in 
>dough either.

I think your points here are excellent and should be made, Richard.  There just
isn't enough business, perhaps.

If I were to counter this argument, I'd probably try and say that C
compilers
and C compiler technology has been around, implemented, re-implemented,
documented, debated, argued over, and pretty much drilled into the ground over
the years and it should be pretty much a given that anyone making a C compiler
can benefit from all that effort that has gone before them.  And that we should
be, today, "standing on the shoulders of giants," as Newton said.

I should not be seeing the same mix of compiler optimizations in the MSP-430
world that I had in my Lattice C v3 compiler, back circa 1985.  I mean... this
IS almost 20 years later, for gosh sake.  And it's not like there
hasn't been
hundreds, if not thousands, of programmers working continuously on a variety of
techniques over time.  It's not like its *research*, you know.  The caveats
have
all been worked out, already.

Of course, I'm not making that argument.  I understand at least *some* of
the
difficulties you and others face.

And to be blunt, Richard, I deeply respect what you've done and what others
have
managed here, as well.  And I deeply respect the fact that you are spending time
here, too, reading and replying.  It's part of what tells me about the
quality
of person you are and how much you care, too.  Please don't take anything I
say
as anything but coming from an immense and abiding respect.

>Writing optimizing compilers takes time, and worse,
can introduce bugs and 
>can make your programs more difficult to debug. It may even expose bugs in 
>YOUR programs, but try to tell that to an engineer whose products have to 
>ship yesterday....

hehe!!  I know!

>Having said that, we are investing resource to do
an optimizer. The proof 
>is in the pudding and we will see how it goes. We aren't afraid to test

>uncharted territories - we have the first whole program code compression 
>engine out in the embedded compiler market in 1999, we were one of the 
>first with easy to use Windows IDE back in the 90s. Look around, we are one 
>of the few compiler companies that cover 6 or more CPUs from 4 different 
>Silicon Vendors and soon we will throw ARM into the mix.

Ah!  Good.  Glad to hear you aren't languishing on that paradise island,
just
yet.  ;)

>Writing compilers have always been my passion. I
have plenty of ideas, it 
>would be a matter of times to put the plans in place.

Well said and much appreciated, Richard!

Jon

On Sun, 8 Aug 2004 21:27:17 +0100, Paul wrote:

>Have you got the wrong end of the stick here, Jon? 
My organic optimizer
>is truly portable--it travels about 5'5" off the ground and is
encased
>in a ballistic container at all times.  I'd be lost without it,
it's so
>precious.  Got it yet?  ;-)
>
>Perhaps you've fallen into the trap of thinking my organic optimizer is
>something other than I do.

No, I understood you.

Jon

On Sun, 8 Aug 2004 21:34:16 +0100, Paul wrote:

>> Because embedded C compiler writers are more
busy writing 
>> fancy IDEs and libraries and wizards and who knows what else.
>
>Well, I've refrained from that.  However, to sell a product these days
>you need the eye candy, or else you'll just die as an outfit.

Understood, of course!  I may be forced to live with it, but I just don't
like
that fact.

>> I just think the embedded compilers could be
SOOOOO much 
>> better.  I think I have an idea just how smart you compiler 
>> writers really are (fantastic, as a guiding rule, I think) 
>> and that I, as an embedded compiler user, shouldn't have to 
>> go begging for something as relatively basic as structure 
>> disaggregation.  And that's only one of so many things.  Yes, 
>> it's work to implement.  But I can think of lots worse things 
>> to waste your time on (like playing nanny in hoisting novice 
>> C compiler writers with wizard tools and pretty colors.)
>
>Actually, breaking a structure memberwise is not as simple as it sounds.
>It can be done, but there are better ways to spend development resources
>than do this, IMNSHO.

Ah?  And have you, yet?  Let's see the list so I can pummel you about why
you
haven't done those, too!!  ;)

>> Of course, that's merely my lay opinion. 
So I'll defer to 
>> your superior, professional knowledge on these points.
>
>It's just a biz decision.  I could contemplate optimizations until I
>have little breath left, but my life isn't measured by what I do or do
>not put into a compiler, thankfully.  Given the choice of adding more
>optimizations to an existing product or writing a new CG for another
>processor, I'd go for the new processor every darned time because
>there's no feeling quite as good as running your first compiled program
>on a machine using your own tools.

By this logic, we'll never get a really top-notch C compiler for embedded
use.
You'll always be chasing the next bit of hardware.  And while I'm sure
it is
very satisfying for you, it's a process that never ends.  You'll be
off chasing
the next nifty processor in greener pastures while us grunt application folks
fend for ourselves on the (then) ancient MSP-430!

Jon

Hi Jon,

> >It's just a biz decision.  I could
contemplate optimizations until I
> >have little breath left, but my life isn't measured by what 
> I do or do
> >not put into a compiler, thankfully.  Given the choice of adding more
> >optimizations to an existing product or writing a new CG for another
> >processor, I'd go for the new processor every darned time because
> >there's no feeling quite as good as running your first 
> compiled program
> >on a machine using your own tools.
> 
> By this logic, we'll never get a really top-notch C compiler 
> for embedded use.
> You'll always be chasing the next bit of hardware.

All I'll say here is that our benchmarks for the MSP430 are very good;
TI provided source code benchmarks to all compiler vendors, and we
submitted our numbers to them.  I've chatted with Anders and Lotta
offline and we've exchanged our benchmark figures and hammered out
exactly how the numbers are made up so there is no misunderstanding, and
for the gudance of other compiler vendors.  If HI-TECH, ImageCraft, or
Quadravox think they've got better optimizers, then it's time for
figures on TI benchmarks.

Unless I'm wrong, IAR and RAL are the only two companies to have
responded to TI's request for benchmark figures.  And all I'll say is
that our benchmark figures are not easily beaten.  Hence, I do think we
have a good system.  Not only that, you don't pay the earth for it.
And, my gawd, does it compile quickly!  And it comes with a useful IDE.

Having looked at a lot of customer code, many optimizations in MSP430
apps are just not applicable because functions intimately deal with
hardware and are naturally short.  It's a tradeoff.  I don't see, for
instance, loop unrolling as a generally profitable optimization on the
MSP, but on a DSP, yeah, go for it!  I can manualy unroll loops if I
have to.  Induction variables?  Use a pointer, as God intended in C.
CSE?  Don't write dunderhead code in the first place.  You get the
picture.

> And while 
> I'm sure it is
> very satisfying for you, it's a process that never ends.  
> You'll be off chasing
> the next nifty processor in greener pastures while us grunt 
> application folks
> fend for ourselves on the (then) ancient MSP-430!

I find very little left to be done on the MSP430 compiler for the
moment.  IAR have let the cat out of the bag somewhat about forthcoming
MSPs, and I don't know if TI will object to that.

-- Paul.

M. Adam Davis wrote:
> Tom Digby wrote:
> 
> 
>>Of course that was twenty years ago.  Twenty years from now they'll

>>probably have interactive compilers that can read pseudo-code, ask 
>>questions about any ambiguities, and optimize even horrendous legacy 
>>bit-twiddling stuff.
>>
>> 
>>
> 
> Yeah, that would be nice.  Of course it /is/ 20 years later since they 
> said we should be having this kind of system.  I guess we got 
> sidetracked by cell phones and this internet thing...
> 
> -Adam

Honestly? Does anybody here in this group really want something like 
this? It defeats the object of doing this kind of work entirely. Perhaps 
a lot of you don't enjoy what you do and got here because you thought 
the money was good. I personally really enjoy what I do, 30 some years 
down the track it's still a kick in the butt to drive 1000 miles on 
software you've just finished testing, or to log into the mining fleet 
you networked 10 years back, and see your stuff still going strong. I 
don't want nannying, governments do too much of that already.

Al

Jon,

> >I would even be more blunt - there are 4 or 5
good compilers 
> for MSP430 out 
> >there. How big do you think the market is?
> 
> I've no idea and, actually, I'd be interested in knowing.  
> Can you share this?
> 
> But it doesn't need to be big, Richard, to support one's own 
> family.  600 copies
> a year at US$200 is US$120k.  Enough to get by and at 50 
> copies a month or about
> 2 a day.  And what a business!!!

It's taken three full-time engineers three years to write the
CrossStudio IDE and port it to various platforms and architectures.
That doesn't include the compiler, linker, and other tools required--the
C compiler existed before that, about five years ago we shipped our
first smart card product.  RAL have invested over GBP 600,000
(converting, > US$1,000,000) in this venture to get ARM, MSP, and AVR
compilers out the door.  Sure, we do other things too.

Yeah, what a business.  Why the hell am I in it?  Perhaps I'll wake up
at some point, realise it's all a bad dream, and scurry off to a nice
cosy job at Microsoft.

I doubt that the MSP430 market, globally, will top 1,000 units a year
for C development tools.  Just look at the "Which C compiler do you
use"
poll...  Perhaps I need to get all my customers to vote and skew it...

-- Paul.

Jon,

> Where Paul was right in the above was in his
"for some 
> systems, the MSP430 and
> assembler are a perfect fit."  But that was buried between 
> the rest.  And the
> rest made the implication that programmers who actually might 
> *reasonably*
> choose to write in assembler, obviously aren't really doing 
> sophisticated
> applications.  And this is wrong.

I don't think I made this point, Jon.  I didn't say, not mean to
infer,
that if you write in assembler you're not developing a sophisticated
systems.

I'm quite happy to code 64K in assembly code for the MSP430, given the
circumstances, but it would not be my first choice.  Having bootstrapped
a complete assembler/linker and integrated editor/debugger for the
Commodore 64 from hand-assembling and typing in hex codes, to writing
mnemonics in assembler (no HLL involved), I can write and appreciate
complex systems all in assembly code.  This was done out of necessity
because, at the time, there was no C64 assembler package, so I wrote my
own.

Having written lots of assembly code for lots of real time systems in my
life, it has its place to wring out performance, or even to write for
something so small or new that it doesn't have a credible compiler.
But, not *my* first choice.

-- Paul.

On Sun, 8 Aug 2004 22:54:45 +0100, you wrote:

>It's taken three full-time engineers three
years to write the
>CrossStudio IDE and port it to various platforms and architectures.

Just *amortize*!

>That doesn't include the compiler, linker, and
other tools required--the
>C compiler existed before that, about five years ago we shipped our
>first smart card product.  RAL have invested over GBP 600,000
>(converting, > US$1,000,000) in this venture to get ARM, MSP, and AVR
>compilers out the door.  Sure, we do other things too.

Could have just lived off the interest and had a lazy life.  But it must be that
you just love us application programmers.

>Yeah, what a business.  Why the hell am I in it? 
Perhaps I'll wake up
>at some point, realise it's all a bad dream, and scurry off to a nice
>cosy job at Microsoft.

hehe.  Then you'll be a lot closer to me.  Two or maybe three hours'
drive.
<evil grin>

>I doubt that the MSP430 market, globally, will top
1,000 units a year
>for C development tools.  Just look at the "Which C compiler do you
use"
>poll...  Perhaps I need to get all my customers to vote and skew it...

Egads!!  No wonder you must traipse off to greener pastures.

  :)

Jon