RE: Re: Development tools for MCF5307

I have intentionally tried to stay away from this discussion concerning quality of the toolset, since this is my first forray into the Motorola/Metrowerks toolset in over 20 years.  I have a 29 year history of developing products starting with doing logic with discrete transistor alu's, micro-programmed IC's, to 8-bit through 32 bit micrpprocessors, thus, I have seen a lot of hardware.  In our business we are constantly faced with the tradeoff between high-level language programming and "C."  Whether it is the quality of the compiler, or the quality of the programmers who are producing the compiler features, or the quality of the management team controlling the development and marketing of the toolset, the real issue is whether or not the toolset is adequate to get the job done.

What amazes me about the current compiler war, is that while the marketable feature list is long, and there are impressive GUI interfaces, when I change the optimization setting from compile for speed, to compile for size, or any of the points in between, the size of the object code does not change by a single word!!!  I then ask myself is this all window dressing?  Is this a warmed over interface, that was designed for 32-bit processors?  Are the instruction set, and register set totally misunderstood by the compiler writers?  Do they have no concept for dealing with the trade-off between speed and size on this processor?  Perhaps there is no trade-off that can be conceived by a programming/management team that may be doing this as a favor to Motorola!!!

The bottom line is this:  As long as the assembler generates the correct bit patterns for the documented instructions, in the real world of getting code working, products can be produced.  As Art has pointed out.

Whenever I get code that is wrong, or fails, I will tend to revert to assembler.  To some of you, that is patent heresy!  I know that, but I refuse to believe that the only way to write code, is to use "C."

My biggest complaint is that the decision has been made, early on it would appear, to not publish the opcodes, and open the door to competition such as the GNU compiler.  While this makes it difficult for us assembly language hackers to assist in debugging the compiler output, it also means that the compiler writers are not on a level playing field, and there are few incentives to invest in the development of good optimization techniques.

Right now, I may have to re-write our proprietary boot loader in assembler, since the original code (written under version 4), now no longer fits into boot flash when compiled by version 5.0.2!!!  It overflows by 75 words, and the increase in size was over 10%.

Respectfully,

Jerry L. Johnson (JJ)
Sheffield Automation, LLC
Fond Du Lac, WI
j...@giddings.com
-----Original Message-----
From: MW Ron [mailto:m...@metrowerks.com]
Sent: Wednesday, December 04, 2002 8:06 AM
To: Art Johnson; Tom Burrell; Coldfire CPU Discussion List
Cc: Corey, Rick; m...@yahoogroups.com; Kevin Ackerley (E-mail); Ed Baillie (E-mail); Ken Andreasen; JB Bjorknas; Greg Clark; Greg Coonley (E-mail); Dick Fons (E-mail)

Subject: [motoroladsp] Re: Development tools for MCF5307
.
.
.
Snipped
...