Oliver, These kinds of discussions rapidly devolve into "I'm right, You're wrong" threads, with an ongoing exchange minutae, strawmen, situational comments, generalizations, and True Beliefs. The flamer with the most free time and general verbosity usually "wins". The thing is, if Cosmic works for you, what I have to say about GNU or any competing commercial compiler is irrelevant. I have no interest in selling you on GNU or anything else. I can only make suggestions based on the info available, and in this case it started with someone asking for a free toolset. We seem to have diverged from that rather rapidly. I made arguable claims (and all relative claims are arguable), but so what? You make the claim that buying is cheaper. I didn't see you make a case for that, other than it took a long time to evaluate a compiler. But that's not a case as you could have just acquired and used it, same as any other (see how easy and pointless this is?). In one of the commercial compilers, I note a significant avoidance of the Y register. It's a respected compiler, but I can easily see how using Y would make for some serious code shrinkage (I'm one of those people who usually checks the compiler's assembly output). But this means nothing- another compiler might use Y, but do something else less than optimal. It doesn't matter on another level: it makes code that is certainly good enough for me. In my "ideal" limited-budget situation, I'd rather spend money on a big honking hardware emulator than any compiler. When you hit certain classes of problems, these things will save your more time than your accumulated vacation. And certainly more than the learning curve difference between any two toolsets several times over. -z --- In , "Oliver Betz" <list_ob@g...> wrote: > Mysterious Mister Z wrote: > > > Oliver, you are partly correct. The GNU compiler made a call to a > > library function for the division, but not the multiplication. Whether > > this is "bad" or not depends on whether or not you like your division > > errors tracable. > > and on the quality of the library routine for division - you didn't > say anything about this. > > > Of course, one example means very little. It's quite possible to > > there are more, but I didn't have the time to investigate this > further, it was cheaper to buy the Cosmic compiler. > > > compare any two compilers with a little selective nitpicking and > > "prove" one is ... well, whatever you want. All this leads to is an > > exchange of strawmen and a flame war, so I won't go there. > > No - it shows that making a _good_ port is much work. Stephane Carrez > did a good job, but he simply doesn't have the time to provide a high > degree of optimization. And there are not as many contributors as > compared to other GCC ports. > > > In my view, the making of compilers is no longer the rocket science it > > used to be. They are all pretty good, and they all have > > No, but it's a _lot_ of work. > > > idiosyncracies. The only things really worth looking at are: > > > > What is the total cost of ownership? > > Will it help you reach deadlines better than another? > > Is the support of a type, level and quality you need? > > Is the value added by included extras (IDE, debug tools, help > > functions and so on) right for YOU? > > Are you comfortable with it's way of doing things? > > So if you have to count your work time, the paid HC12 compilers are > still cheaper. > > [...] > > > Where I work, we have embedded tools for some 8 different processors, > > and a near equal variety of tools. One engineer abandoned a "high end" > > gui-based IDE in favor of a variety of command line tools and > > standalone editors (he still uses the package's underlying compiler, > > I use the Cosmic compiler with make, makedepend and my favourrite > editor. Setting the compiler options and making a link file are the > only specific tasks. > > [...] > > > Code generation is rarely (never?) the issue. You can't evaluate it > > Code generation is the main issue if it's bad. If a long/long > division takes 2000 cycles instead of 200, you could be in a > situation where it's simply not possible to do the job. Or if your > interrupt routine has to save several bytes to local storage > therefore being slower and/or not re-entrant. > > [...] > > > I still stand by my assertion that GNU is the way to go when you have > > time but not money. But it is not the only consideration of course. > > Ack. But I didn't see this statement in your original post. You only > wrote "The code quality is as good as any commercial compiler, IMO." > And that's not true. The commercial compilers generate nearly optimal > code (at least the two expensive ones). Rarely you can make it much > better by using assembler. > > Oliver > -- > Oliver Betz, Muenchen

Mysterious Mister Z wrote: > Oliver, you are partly correct. The GNU compiler made a call to a > library function for the division, but not the multiplication. Whether > this is "bad" or not depends on whether or not you like your division > errors tracable. and on the quality of the library routine for division - you didn't say anything about this. > Of course, one example means very little. It's quite possible to there are more, but I didn't have the time to investigate this further, it was cheaper to buy the Cosmic compiler. > compare any two compilers with a little selective nitpicking and > "prove" one is ... well, whatever you want. All this leads to is an > exchange of strawmen and a flame war, so I won't go there. No - it shows that making a _good_ port is much work. Stephane Carrez did a good job, but he simply doesn't have the time to provide a high degree of optimization. And there are not as many contributors as compared to other GCC ports. > In my view, the making of compilers is no longer the rocket science it > used to be. They are all pretty good, and they all have No, but it's a _lot_ of work. > idiosyncracies. The only things really worth looking at are: > > What is the total cost of ownership? > Will it help you reach deadlines better than another? > Is the support of a type, level and quality you need? > Is the value added by included extras (IDE, debug tools, help > functions and so on) right for YOU? > Are you comfortable with it's way of doing things? So if you have to count your work time, the paid HC12 compilers are still cheaper. [...] > Where I work, we have embedded tools for some 8 different processors, > and a near equal variety of tools. One engineer abandoned a "high end" > gui-based IDE in favor of a variety of command line tools and > standalone editors (he still uses the package's underlying compiler, I use the Cosmic compiler with make, makedepend and my favourrite editor. Setting the compiler options and making a link file are the only specific tasks. [...] > Code generation is rarely (never?) the issue. You can't evaluate it Code generation is the main issue if it's bad. If a long/long division takes 2000 cycles instead of 200, you could be in a situation where it's simply not possible to do the job. Or if your interrupt routine has to save several bytes to local storage therefore being slower and/or not re-entrant. [...] > I still stand by my assertion that GNU is the way to go when you have > time but not money. But it is not the only consideration of course. Ack. But I didn't see this statement in your original post. You only wrote "The code quality is as good as any commercial compiler, IMO." And that's not true. The commercial compilers generate nearly optimal code (at least the two expensive ones). Rarely you can make it much better by using assembler. Oliver -- Oliver Betz, Muenchen

--- In , "Oliver Betz" <list_ob@g...> wrote: > Mysterious Mister Z wrote: > > [GNU C for the HC12] > > > The code quality is as good as any commercial compiler, IMO. > > Which of them do you know (Cosmic, Metrowerks, ICC...)? > > I assume you have some experience with GCC/HC12. I also had to decide > which compiler to use but I found that some library functions were > pretty bad. Nevertheless I'm interested how GNU C for the HC12 is > improved. > > Could you please tell me how long (CPU cycles) an (unsigned > long)/(unsigned long) division and a (float)/(float) division takes > in the recent version? > > If there is still no reasonable int math, I'm afraid that float > division is faster than long (thanks to Tim Housel). > > Does the compiler use the 32 bit HC12 operations where possible, e.g. > > U16 X, Y, Z; > X = (U16)(((U32)Y * 1000) / (U16)Z); > > should use only emul and ediv, no library call. > > After all, I really dislike the usage of soft registers (because I > use many interrupts). IMHO, for the HC12 it's not really necessary. > > Oliver > -- > Oliver Betz, Muenchen Oliver, you are partly correct. The GNU compiler made a call to a library function for the division, but not the multiplication. Whether this is "bad" or not depends on whether or not you like your division errors tracable. Of course, one example means very little. It's quite possible to compare any two compilers with a little selective nitpicking and "prove" one is ... well, whatever you want. All this leads to is an exchange of strawmen and a flame war, so I won't go there. In my view, the making of compilers is no longer the rocket science it used to be. They are all pretty good, and they all have idiosyncracies. The only things really worth looking at are: What is the total cost of ownership? Will it help you reach deadlines better than another? Is the support of a type, level and quality you need? Is the value added by included extras (IDE, debug tools, help functions and so on) right for YOU? Are you comfortable with it's way of doing things? Each of these is somewhat situational as well. If you are on a tight budget, tool costs can be a very big deal (consider a price range that varies from $0 to $5,000 or more - $5,000 buys a fair bit of learning time, parts, protoype boards and so on). But familiarity might also play a part. If you know and use toolset X and its features, it's probably something you want to stay with. Where I work, we have embedded tools for some 8 different processors, and a near equal variety of tools. One engineer abandoned a "high end" gui-based IDE in favor of a variety of command line tools and standalone editors (he still uses the package's underlying compiler, linker, etc). He and I both have problems with tools that too often do more than you want, and have learning curves that are just as brutal as "manual" methods. Yet there are others here who would never consider anything but fat point-and-click wrappers around the compiler/linker/debugger set. To each his own. Code generation is rarely (never?) the issue. You can't evaluate it anyway, except in your own projects and by actually using several tools. A very expensive and time consuming proposition. Generalisms don't apply because everybody is releasing new stuff and bugfixes all the time - generalisms become dated very fast. I still stand by my assertion that GNU is the way to go when you have time but not money. But it is not the only consideration of course. -z

Daniel Friederich wrote: > the problem for an ANSI C compiler with performing > > U16 X, Y, Z; > X = (U16)(((U32)Y * 1000) / (U16)Z); > > with an EMUL and an EDIV is that if the 32/16 bit EDIV division overflows, then the > HC12 does not generate a result at all (it just sets the V flag). > Therefore using a simple EDIV does not generate the same result Right, I forgot to mention this. Therefore one can tell the "advanced" compiler that he is aware of this "problem" and wants to have the fast but not 100% ANSI solution. After all, in _most_ cases the result of an overflowed division is useless, no matter whether it's the truncated correct result or something else. As Bob Gardner wrote: it would be interesting how this is handled by the other (ICC, GCC) compilers: is it possible to use the fast "ediv" version, and how do I tell it the compiler? Can I set it on a "per statement" basis (Cosmic typecast) or on a "per file" basis (Hiware - pediv)? BTW: a #pragma would be the cleanest solution, wouldn't it? > Apart from this, we are also not using any "soft registers". It would also be interesting to know whether e.g. ICC still needs them. Oliver -- Oliver Betz, Muenchen

wrote: > U16 X, Y, Z; > X = (U16)(((U32)Y * 1000) / (U16)Z); > > should use only emul and ediv, no library call. > ================================= > This is a result I'd like to see for each compiler. well, Cosmic produces this (obviously without the comments): ldd _Y ldy #1000 ; works also with a variable emul ldx _Z ; works also with a constant value ediv sty _X it's a piece of code I use pretty often for fast (fixed point) scaling, and I was happy to see that Cosmic produces optimal code. Oliver -- Oliver Betz, Muenchen

Hi Oliver, the problem for an ANSI C compiler with performing U16 X, Y, Z; X = (U16)(((U32)Y * 1000) / (U16)Z); with an EMUL and an EDIV is that if the 32/16 bit EDIV division overflows, then the HC12 does not generate a result at all (it just sets the V flag). Therefore using a simple EDIV does not generate the same result for all possible Y and Z's as calculating it with longs. Our metrowerks compiler does generate the code you are expecting, but only if you are specifying the option -PEDiv. The default is the save (and slower) long division. Apart from this, we are also not using any "soft registers". Bye Daniel > -----Original Message----- > From: Oliver Betz [mailto:] > Sent: Friday, August 08, 2003 17:06 > To: > Subject: Re: [68HC12] Re: 68hc12 C compiler and assembly instruction set > Mysterious Mister Z wrote: > > [GNU C for the HC12] > > > The code quality is as good as any commercial compiler, IMO. > > Which of them do you know (Cosmic, Metrowerks, ICC...)? > > I assume you have some experience with GCC/HC12. I also had to decide > which compiler to use but I found that some library functions were > pretty bad. Nevertheless I'm interested how GNU C for the HC12 is > improved. > > Could you please tell me how long (CPU cycles) an (unsigned > long)/(unsigned long) division and a (float)/(float) division takes > in the recent version? > > If there is still no reasonable int math, I'm afraid that float > division is faster than long (thanks to Tim Housel). > > Does the compiler use the 32 bit HC12 operations where possible, e.g. > > U16 X, Y, Z; > X = (U16)(((U32)Y * 1000) / (U16)Z); > > should use only emul and ediv, no library call. > > After all, I really dislike the usage of soft registers (because I > use many interrupts). IMHO, for the HC12 it's not really necessary. > > Oliver > -- > Oliver Betz, Muenchen > > -------------------- > > ">http://docs.yahoo.com/info/terms/

In a message dated 8/8/03 11:06:58 AM Eastern Daylight Time, writes: Does the compiler use the 32 bit HC12 operations where possible, e.g. U16 X, Y, Z; X = (U16)(((U32)Y * 1000) / (U16)Z); should use only emul and ediv, no library call. ================================= This is a result I'd like to see for each compiler.

Mysterious Mister Z wrote: [GNU C for the HC12] > The code quality is as good as any commercial compiler, IMO. Which of them do you know (Cosmic, Metrowerks, ICC...)? I assume you have some experience with GCC/HC12. I also had to decide which compiler to use but I found that some library functions were pretty bad. Nevertheless I'm interested how GNU C for the HC12 is improved. Could you please tell me how long (CPU cycles) an (unsigned long)/(unsigned long) division and a (float)/(float) division takes in the recent version? If there is still no reasonable int math, I'm afraid that float division is faster than long (thanks to Tim Housel). Does the compiler use the 32 bit HC12 operations where possible, e.g. U16 X, Y, Z; X = (U16)(((U32)Y * 1000) / (U16)Z); should use only emul and ediv, no library call. After all, I really dislike the usage of soft registers (because I use many interrupts). IMHO, for the HC12 it's not really necessary. Oliver -- Oliver Betz, Muenchen