On Fri, Aug 06, 2004 at 06:28:54PM +0930, onestone wrote:
> Neither, only assembler can do that. ;@}

Dont forget you need a onstone too. :-)

M.

> Al
> 
> Leonard Braun wrote:
> > But which compiler generates faster and smaller code?
> >  
> >   _____  
> > 
> > From: Robert Wood [mailto:robert.wood@robe...] 
> > Sent: Thursday, August 05, 2004 6:57 PM
> > To: msp430@msp4...
> > Subject: Re: [msp430] IAR or CrossWork
> >  
> > 
> >>>Which C compiler would you recomend?
> > 
> > I've narrowed it down to these two as they are the ones which 
> > support doubles and long longs. <<
> > 
> > I've used both and would unreservedly recommend the Crossworks.
It works
> > very 
> > well, the code is very, very easy to port from IAR and Crossworks is
> > much 
> > cheaper. 
> > 
> > Also, technical help is much better from Rowley I have found. Very
> > responsive. 
> > Rowley have got this USB JTAG interface to go with Crossworks as well
> > which 
> > apparently is much quicker than the parallel port one. 
> > 
> > Cheers,
> > 
> > Rob
> > 
> > 
> > .
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > click here
> >
<http://us.ard.yahoo.com/SIG9bsuhov/M)5196.4901138.6071305.3001176/
> > D=groups/S05005378:HM/EXP91836506/A!28215/R=0/SIGse96mf6/*htt
> > p:/companion.yahoo.com> 
> >  
> >
<http://us.adserver.yahoo.com/l?M)5196.4901138.6071305.3001176/D=group
> > s/S=:HM/A!28215/rand0211558> 
> >  
> >   _____  
> > 
> > > . 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > .
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> > 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
        Matthias

Robert Wood wrote:
> Leonard queried of IAR and Crossworks:
> 
> "But which compiler generates faster and smaller code?"
> 
> All I can offer is the fact that when I compiled the code for the project I

> ported, the IAR generated an Intel Standard file (which I assume is, and 
> looks like, Intel Hex) of 27k. The Crossworks says 26.2k for the same
format. 
> Whether that proves anything I'm not sure.
> 
> Also, which one is faster I don't know, but I'm not sure I'd
run the MSP430 in 
> time critical application! 
> 
> Cheers,
> 
> Rob
> 
> PS Al said and brought a broad grin to my face:
> 
> "Neither, only assembler can do that. ;@}"
> 
> Nice one, Al! :)

Thanks Rob, By the way I mostly use the MSP430 in time critical 
applications.

Al

I believe it's the big programs, not the small ones where we gain.
Take 
any small piece of code and it is extremely easy to compress. take an 
entire application and C programmers think differently to assembler 
programmers, and therein lie the gains. Also optimisation of register 
usage can often better be seen by an assembler programmer.

This begs the question, raised by another thread. To truly optimise the 
MSP430 code you need an intimate knowledge of the instruction set, and 
cycle timing, to achieve this degree of optimisation a compiler MUST be 
cycle counting. Do any of the compilers store/print/list these cycle times?

Al

Richard (UK). wrote:

> The MNF Fortran IV compiler for the CDC6600 /
CDC7600 minicomputer back in the late 70s when operated in full aggressive
compile
> mode [13 passes, multi-hour compiles] was believed to produce more
efficient code than Assembler writers ... although how they
> measured that I have no idea!
> 
> So I assume there must be some compilers nowadays [probably for the PC
& PowerPC] which can outrun Assembler writers even for small
> programs.
> 
> regards,
> 
> Richard (UK)
> 
> 
> ----- Original Message ----- 
> From: "Robert Wood" <robert.wood@robe...>
> To: <msp430@msp4...>
> Sent: Friday, August 06, 2004 6:17 PM
> Subject: Re: [msp430] IAR or CrossWork
> 
> 
> 
>>Leonard queried of IAR and Crossworks:
>>
>>"But which compiler generates faster and smaller code?"
>>
>>All I can offer is the fact that when I compiled the code for the
project I
>>ported, the IAR generated an Intel Standard file (which I assume is, and
>>looks like, Intel Hex) of 27k. The Crossworks says 26.2k for the same
format.
>>Whether that proves anything I'm not sure.
>>
>>Also, which one is faster I don't know, but I'm not sure
I'd run the MSP430 in
>>time critical application!
>>
>>Cheers,
>>
>>Rob
>>
>>PS Al said and brought a broad grin to my face:
>>
>>"Neither, only assembler can do that. ;@}"
>>
>>Nice one, Al! :)
>>
>>
>>
>>
>>
>>
>>
>>  _____
>>
>>
>>
>>
>>.
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
> 
> 
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/04
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 

There are many more out there far better than I. I just have the biggest 
mouth. ;@}

Al

Matthias Weingart wrote:

> On Fri, Aug 06, 2004 at 06:28:54PM +0930,
onestone wrote:
> 
>>Neither, only assembler can do that. ;@}
> 
> 
> Dont forget you need a onstone too. :-)
> 
> M.
> 
> 
>>Al
>>
>>Leonard Braun wrote:
>>
>>>But which compiler generates faster and smaller code?
>>> 
>>>  _____  
>>>
>>>From: Robert Wood [mailto:robert.wood@robe...] 
>>>Sent: Thursday, August 05, 2004 6:57 PM
>>>To: msp430@msp4...
>>>Subject: Re: [msp430] IAR or CrossWork
>>> 
>>>
>>>
>>>>>Which C compiler would you recomend?
>>>
>>>I've narrowed it down to these two as they are the ones which 
>>>support doubles and long longs. <<
>>>
>>>I've used both and would unreservedly recommend the Crossworks.
It works
>>>very 
>>>well, the code is very, very easy to port from IAR and Crossworks is
>>>much 
>>>cheaper. 
>>>
>>>Also, technical help is much better from Rowley I have found. Very
>>>responsive. 
>>>Rowley have got this USB JTAG interface to go with Crossworks as
well
>>>which 
>>>apparently is much quicker than the parallel port one. 
>>>
>>>Cheers,
>>>
>>>Rob
>>>
>>>
>>>.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>click here
>>><http://us.ard.yahoo.com/SIG9bsuhov/M)5196.4901138.6071305.3001176/
>>>D=groups/S05005378:HM/EXP91836506/A!28215/R=0/SIGse96mf6/*htt
>>>p:/companion.yahoo.com> 
>>> 
>>><http://us.adserver.yahoo.com/l?M)5196.4901138.6071305.3001176/D=group
>>>s/S=:HM/A!28215/rand0211558> 
>>> 
>>>  _____  
>>>
>>>> . 
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>.
>>>
>>> 
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>> 
>>>
>>>
>>
>>
>>
>>
>>.
>>
>> 
>>Yahoo! Groups Links
>>
>>
>>
>> 
>>
> 
>         Matthias
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 

Al, 

> I believe it's the big programs, not the
small ones where we 
> gain. Take any small piece of code and it is extremely easy 
> to compress. take an entire application and C programmers 
> think differently to assembler programmers, and therein lie 
> the gains. Also optimisation of register usage can often 
> better be seen by an assembler programmer.
> 
> This begs the question, raised by another thread. To truly 
> optimise the MSP430 code you need an intimate knowledge of 
> the instruction set, and cycle timing, to achieve this degree
> of optimisation a compiler MUST be cycle counting. Do any of 
> the compilers store/print/list these cycle times?

Code generation is a combination of techniques, some of which work most
of the time.  Our compiler weighs variable references and generates code
according to a couple of metrics.

If you are compiling to reduce code size, the compiler assigns a simple
count of the references to the variable in a function and then allocates
registers to the most used register first, down to the least used
register.  This reduces the code size because frequently-referenced, on
a static basis, are allocated to registers.  The ones that are
infrequently used in a function may get punted to memory.

When compiling to optimize speed, the compiler assigns a dynamic
reference count to the variable weighed by loop depth and if-else branch
frequency (50-50 at present) and so on.  This is an estimate of how much
the variable will be used at runtime.  The compiler then assigned the
most heavily used variable to registers first because it will benefit
most from registerization.

Of course, there are other heuristics used in the compiler, but they're
just too boring and complex to go into.

-- Paul.

Hello al[l],

well I guess a compiler never can replace a good programmer with
experience. What was designed or written inefficiently cannot be
corrected by a compiler unless it would be artifical lifeform with
understanding (and also a lot of experience and training).

I think the problem also applies more to micros or small cpus like
the msp. If you take a look at intels optimization docs for the
pentiums, that are hundreds and hundreds of pages I don't want to
know. I guess (and a colleage even tried) it is very difficult
to compete with a compiler that knows about all that pipelines
and "do's and don'ts" etc.

So in my opinion you must roughly have in mind what you want to
achieve with the high language code and then it's fair to
handcraft some time critical or otherwise critical parts of  the
progam in asm to either get the speed or the desired size. The
rest doesn't matter. I don't care if the program fits into the
memory and does its job,  if I used 10% or 30% of the device's
memory. If price and model (a smaller one) matters, good, go out
and improve - that is "worth" it.

For me high level syntax is a convenient way of having sort of
"portable" code. I do it and I also see others do it: You can
have a "C-Version" of the function and branch it with precompiler
directives to target optimized inline asm versions for different
targets. I often try out some algorithms or parts of a program
on my x86 box printf-ing because it's fast.

Everything moves so fast its hard to keep up with asm versions.
On the other hand you have a deep understanding of the platform
you're coding for. If you need that depends on what you're after.

Of course that does apply only to "applications" and not things
like OS kind of things.

Greetz,

	Georg

onestone wrote:
> Paul Curtis wrote:
> 
>>Al, 
>>
>>
>>
>>>I believe it's the big programs, not the small ones where we 
>>>gain. Take any small piece of code and it is extremely easy 
>>>to compress. take an entire application and C programmers 
>>>think differently to assembler programmers, and therein lie 
....

Paul Curtis wrote:
> Al, 
> 
> 
>>I believe it's the big programs, not the small ones where we 
>>gain. Take any small piece of code and it is extremely easy 
>>to compress. take an entire application and C programmers 
>>think differently to assembler programmers, and therein lie 
>>the gains. Also optimisation of register usage can often 
>>better be seen by an assembler programmer.
>>
>>This begs the question, raised by another thread. To truly 
>>optimise the MSP430 code you need an intimate knowledge of 
>>the instruction set, and cycle timing, to achieve this degree
>>of optimisation a compiler MUST be cycle counting. Do any of 
>>the compilers store/print/list these cycle times?
> 
> 
> Code generation is a combination of techniques, some of which work most
> of the time.  Our compiler weighs variable references and generates code
> according to a couple of metrics.

In my first para the suggestion is that compilers can only have a 
limited effect in their attempts at optimisation, because often the code 
is written in such a manner that even when optimised it is not optimal. 
I see examples of this here all the time

> 
> If you are compiling to reduce code size, the compiler assigns a simple
> count of the references to the variable in a function and then allocates
> registers to the most used register first, down to the least used
> register.  This reduces the code size because frequently-referenced, on
> a static basis, are allocated to registers.  The ones that are
> infrequently used in a function may get punted to memory.

Yes but this is generalised. Even the concept of optimising for speed OR 
optimising for size is a HLL mindset. frankly I almost never have to 
optimise for size. I've never come close to using the 60k of my 
MSP430F149 up. My two most complex projects are probably what I call 
MANIC, and my oyster grader. The majority of memory used in the latter 
is graphics data, character sets etc, while the majotiy of memory in 
MANIC is the GIS translator. the Oyster grader has 2080H bytes of code. 
Now many might think that's a pretty trivial system, but this is what it 
  is. Imagine a 30cm cube. On top is a 40cm tube of 85mm diameter with a 
slight curvature from mid point. At mid point is a laser edge detector.

An oyster is thrown into the top of the tube by a rotating separator. As 
it passes the first edge detector it triggers a bio mass scanner that 
occupises the lower tube section. This scans a total 0f 64 sensors, 
individually  as the oyster falls, building a 3D image of the oyster 
interior as it does so. This is plotted realtime on the graphics panel.

At the bottom is a similar edge detector. as the oyster passes this it 
triggers the optical scanner. 3mm below the top of the cube is an 
octagonal imaging compartment, 4 emitter banks and 4 detector banks, 128 
emitters per bank, 512 detectors (beam spread). because beamspread is so 
bad I must read every 32nd detector individually. there are therefore 32 
individual scan sections per array pair. Only one array pair can eb 
active at a time, to prevent cross talk. this happen becasue the entire 
machine must be fully immersble in sea water. It operates at sea in some 
applicatiosn, thus the interior of the cube has a tubular glass section 
to guide the oyster, and a box section isolating the optics. reflection 
from the glass is an issue. As the oyster passes a new scan line is 
built every 200microseconds. This creates a 3D external image of the oyster.

Oysters may be up to 150mm long. As soon as the oyster has completely 
transistioned the scanner it's length, volume, and relative biomass must 
be calculated, it then is sorted into one of 10 sorting lines. These are 
typivcally sacks, but include a return conveyor, and possibly other 
conveyors. The pysical sorting is done by a motor and cradle which sits 
under the cube, with thew top of the cradle slightly inside, thus the 
oyster is scanned for 150mm, then in less than 150mm it must be sorted 
and the motor positioned. The motor drive is also performed by the 
MSP430. In addition to bio scanner, optical scanner, 3phase dd 
positional motor control, user interface, and real time graphics the 
system must also detect and determine potential collisions. Oysters are 
knobbly things, and can stick together, or simply just drop as a pair. 
The shells also break up on transit so the system must detect and avoid 
collisions, re-route the oysters if they cannot be separated, ignore 
shrapnel, detect interior and exterior jams, clear the jams, restart 
automatically, and moitor the jam/collision frequency to adjust the 
speed of the feed separator motor. Finally if all else goes wrong, or 
someone gets in the way of the sorter It'll tear your hand off) it must 
handle feed conveyors where used, and safety interlocks.

I would suggest this is not a trivial system. And, PLEASE, this is not a 
'how clever am I' post. But too often people have preformed ideas
that, 
to be complex, or significant programs must be huge. I contend the 
opposite almost.

Now back OT. To do this, especially the scanning functions, the system 
has to be blazingly quick. It scans 4*32 sequences, reads them back byte 
wise, unscrambles each byte, back to the original bit positions, then 
updates the graphic display in 200usecs. To achieve that, I beleive, is 
beyond the optimisation capability of any compiler. It is further 
complicated by the need to ensure that every pass takes exactly the same 
number of clock cycles. This first entailed unravelling all the function 
calls. for example in the graphics area a byte write becomes an or'd 
line write, then the code/data command comes out of a function, called 
from a loop, and is inlined, then code re-ordering such that the delays 
between setting pins, and clearing them loses a NOP (necessary due to 
hardware time to set) and sunstitutes with an out of sequence instruction.

The natural tendency of C programmers is to have layered functions 
calling each other, ie:-

	for(i=0;i<40;i++)
	{
		writebyte(data[i]);
	}
	....

writebyte(x)
{
	send_command(write);
	send_data(x);
}

etc etc (don't get on my case about the code, it's merely an example
of 
the program structure I see posted here every day.

In the above, even with optimisation set for speed, could your compiler 
figure out that it would be best to inline everything? Or to restructure 
such that an entire row was accumulated before any write was done, so 
that advantage could be taken of the block write function.

I'M NOT CRITICISING YOUR COMPILER, OR ANY OTHER COMPILER, I'M MERELY 
TRYING TO MAKE A POINT THAT OPTIMISATION IS OFTEN OUT OF THE HANDS OF 
THE COMPILER BECAUSE IT CAN ONLY OPTIMISE WHAT IT SEES, AND MOST C 
PROGRAMS OF ANY LENGTH I HAVE STUDIED ARE EITHER SO OBFUSE THEY ARE 
LITTLE BUT JUNK when it comes to trying to support them, OR WRITTEN IN 
THIS LINEAR TOP DOWN STYLE.

> When compiling to optimize speed, the compiler
assigns a dynamic
> reference count to the variable weighed by loop depth and if-else branch
> frequency (50-50 at present) and so on.  This is an estimate of how much
> the variable will be used at runtime.  The compiler then assigned the
> most heavily used variable to registers first because it will benefit
> most from registerization.

Again optimisation of an entire program is uusually much more than 
tweaking the odd register use. Although the MSP430 particularly lends 
itself to massive gains in speed using this method.


> 
> Of course, there are other heuristics used in the compiler, but
they're
> just too boring and complex to go into.

Don't get me wrong. I believe that you probably have the most optimised 
compiler around. And that you, michel and Richard all do an excellent 
job, both in your products and your support. Heck, even IAR must be 
improving, Anders certainly is a different face to IAR than I have 
previously experienced.

That most people are happy with the way they write code, and then use 
the compiler to get the best out of it, is obvious. Years of hand 
tweaking pure binaries has obviously left me seriously brain damaged.

Of course I have absolutely no one to answer to, so can afford to do as 
I please. Not many people are that lucky.

Al

onestone wrote:

> Yes but this is generalised. Even the concept of
optimising for speed OR 
> optimising for size is a HLL mindset. frankly I almost never have to 
> optimise for size. I've never come close to using the 60k of my 
> MSP430F149 up. My two most complex projects are probably what I call 
> MANIC, and my oyster grader. The majority of memory used in the latter 

I'm reminded that my first attempt at a digital clock track manager for 
an analog tape machine, in 6800 assembler, was a couple dozen bytes too 
big to fit into the 2716 EPROM I was using.  But I was able to 
reorganize things to make it fit.

At one point I had a 36-bit (plus sync bits) data word that might or 
might not, depending on which direction the tape was moving, need to be 
reversed end to end, bitwise.  Or sometimes it was a 24-bit word (plus 
sync bits), depending on what version of the hardware had recorded the 
tape.  I couldn't revise the latter format because it had to be 
compatible with an earlier hardwired-logic implementation.

This bit reversal was fairly easy to do in assembler using the 6800 ROLA 
and RORB instructions on 16-bit chunks of the data word.  I don't know 
how I would have done it in C.

Later, in an application to read IRIG time code, I had to deal with a 
format where every fifth bit in the BCD data stream was a spacer bit or 
some such that had to be discarded.  Again, this was easier in assembler 
than I think it would have been in C.

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.


--
                        -- Tom Digby
                        bubbles@bubb...
                        http://www.well.com/~bubbles/
                        http://www.well.com/~bubbles/BblB60DL.gif

Hi Georg,

Georg Ritter wrote:
> Hello al[l],
> 
> well I guess a compiler never can replace a good programmer with
> experience. What was designed or written inefficiently cannot be
> corrected by a compiler unless it would be artifical lifeform with
> understanding (and also a lot of experience and training).

It is also true that you can write bad code in any language.

> 
> I think the problem also applies more to micros or small cpus like
> the msp. If you take a look at intels optimization docs for the
> pentiums, that are hundreds and hundreds of pages I don't want to
> know. I guess (and a colleage even tried) it is very difficult
> to compete with a compiler that knows about all that pipelines
> and "do's and don'ts" etc.

Very much so. I used to write in assembler under DOS up to the '486, but 
typically only speed critical stuff. I didn't prototype my code in C 
under DOS, as much as I'd use C to quickly check out an idea, without 
the need for hardware, confirm my brain still functioned then go ahead 
and design the hardware/embedded software.

> 
> So in my opinion you must roughly have in mind what you want to
> achieve with the high language code and then it's fair to
> handcraft some time critical or otherwise critical parts of  the
> progam in asm to either get the speed or the desired size. The
> rest doesn't matter. I don't care if the program fits into the
> memory and does its job,  if I used 10% or 30% of the device's
> memory. If price and model (a smaller one) matters, good, go out
> and improve - that is "worth" it.
> 
> For me high level syntax is a convenient way of having sort of
> "portable" code. I do it and I also see others do it: You can
> have a "C-Version" of the function and branch it with precompiler
> directives to target optimized inline asm versions for different
> targets. I often try out some algorithms or parts of a program
> on my x86 box printf-ing because it's fast.
> 
> Everything moves so fast its hard to keep up with asm versions.

I'd suggest C and the various compilers change far more frequenctly than 
assembler does. That's one reason I like it. It is what it is, there is 
no need to mess with it once it works. I also believe very strongly that 
  separating hardware and software design just doesn't work for embedded 
systems, especially smaller ones (say below 64k code area). Whichever 
side of the fence you originated from you simply have to be good at both 
hardware and software design if you want produce competitive designs 
that are better, faster and cheaper. And, yes, I really do believe you 
can have all three. If you don't believe that why be in this business?

Equally I agree that things are moving away from very low level stuff, 
but there will always be a place for it. I believe the trend to HLL's is 
  as much to get bums on seats as any other reason. This applies more to 
C++ than C, And even more to the PC world. There is a dearth of really 
top  quality programmers, answer? Don't train more, make it easier, then 
  just throw endless power at the task until it works. Bluetooth is the 
embedded worlds version of this. It truly is an elephant (which, for 
those whose first language isn't English, is a mouse designed by 
committee.) Likewise the trend to so called 'smart sensors', as 
discussed here a while ago.

Al

> On the other hand you have a deep understanding of
the platform
> you're coding for. If you need that depends on what you're after.
> 
> Of course that does apply only to "applications" and not things
> like OS kind of things.
> 
> Greetz,
> 
> 	Georg
> 
> onestone wrote:
> 
>>Paul Curtis wrote:
>>
>>
>>>Al, 
>>>
>>>
>>>
>>>
>>>>I believe it's the big programs, not the small ones where
we 
>>>>gain. Take any small piece of code and it is extremely easy 
>>>>to compress. take an entire application and C programmers 
>>>>think differently to assembler programmers, and therein lie 
> 
> ....
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 

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