At 01:02 PM 3/28/2005 -0600, you wrote: >... > >We are using an IP core and not a real HC11 so we need access to the C >runtime source (and preferably library). Most of the native HC11 >registers and peripherals are either not supported or implemented >differently so we need to be able to customize the library source if it >depends upon them. We are currently using the Imagecraft product and >have exceeded the amount of code space that we would like to use, so >good optimization is a must. We are using the NoICE debugger and it >would be helpful if the object file format was supported by the >compiler/linker. > >I have the non-commercial license of Introl which won't help me much >and it doesn't belong to my company either. >Thanks, >Mike Mike, I mostly just linger, and my 68HC11 projects (so far) haven't been quite as lengthy as yours. However, I may have a few hints which may help you with the ICC compiler. Since your core doesn't have most of the registers, then I would suggest not using the include-file that has all of the HC11 defines. You mentioned something about the start-up code produced by the compiler was trying to write to some of these registers: I recently had to dig through and locate the default start-up code and modify it. You should be able to do the same per your requirements. One trick with the start-up code is that it is all written in assembler, and you have to use the Imagecraft assembler to assemble it to be compatible with their compiler. The command-line for running the assembler was omitted from the V6 compiler manual, but it is listed in the V5 manual. One of the problems I found with my code concerned the way I had written a number of pre-initialized character arrays to hold various canned messages I needed. I found that the compiler's startup code was copying these arrays from eprom space into ram space, and using the ram copies as the program calls upon them. This was rather wasteful, and not what I would consider "documented." I was able to shift to using just the epromed arrays by declaring the arrays as CONST. In hindsight, this seemed pretty obvious to me. My thought was that maybe you have some similar blocks of code that can be changed to free up some address space. I don't use most of the standard libraries that come with the compiler because they don't meet my requirements i.e. they don't know how to talk to my LCD or use my protocal when using the serial port. I don't know why you can't just modify the given libraries to suit your requirements, since all the source is supplied. What I am looking forward to is the 68HC11 V7 compiler, which is supposed to support some C++ extensions, some of which may help some of my projects, if not yours :) Steve

--- In m68HC11@m68H..., "Robert L. Doerr" <rdoerr@b...> wrote: > Hello Mike, > > From your post you said that you are using an IP HC11 core > instead of a real 68HC11 and that the core implements things > differently. What are the differences? Does it lack a lot > of the built-in features of the real chip? It does not contain most of the built-in peripherals. It only supports about two of the native 68hc11 registers (INIT, OPTION?). > > It sounds like you are asking for two different things. First, > a way to alter the way the compiler generates it's code to > compinsate for the difference in the IP core you are using. > Second, you are looking for a C compiler that will generate > more compact code. Are these correct assumptions? Not generate different code, just don't assume the peripherals and control registers are there. Yes, generate more compact code. > For the first item I would ask that question to the supplier > of the IP core that you are using. If it is different what > tools are normally used to generate code for it? No. > If the compiler you are using can't generate code that will > fit can you take another look at the algorithms you are coding > in C to deterime if you can do it a shorter way? Take a step > back or have someone else take a look. Sometimes a fresh > perspective is all that is needed. The sheer volume of tasks the system has to perform is the driving force for the amount of code generated. Normally I would look to processor with greater addressing capability, but that wasn't possible given that a core had to be selected to fit within the available FPGA. My gut feeling is that the pointer arithmetic for our complicated data structures is killing us, but it would turn into an unwieldy mess without them. > If all else fails you could look at some of the other programming > tools for the 68HC11. Assembly is what I prefer but supposedly > there is a Tiny4th and SBASIC compiler for the 68HC11 that may > also do the job. I've written most of the time-critical stuff in assembly already, but I may need to convert some of the other stuff too. The nature of the project is such that I can't use anything other than a pure ANSI C compiler. > Good Luck, Thanks I'm probably going to need it... Mike

Talk to Dave Dunfield http://www.dunfield.com/ he has a compiler linker and assembler he supports himself via email for 99 bucks. His startup assembly is pretty short and well commented and get a copy of Plunger's C library and implement you own library functions. Just putting in what you need. If you stay away from functions like printf() than take over 1,000 bytes of run time code you can pack a lot program in 64K. Dunfield's code compares favorably with the old Intol compiler it doesn't support longs but has a variable length integer that works fine but is slow. It has no floating point either. If you are doing floats you need another chip that implements floating point math any work around for floating point is terribly slow on a 68HC11. I have yet to see any application that fixed point didn't work better than floating point. Gordon Couger Stillwater, OK www.couger.com/gcouger David Kelly wrote: > > On Mar 28, 2005, at 2:07 PM, Robert L. Doerr wrote: >> From your post you said that you are using an IP HC11 core >>instead of a real 68HC11 and that the core implements things >>differently. What are the differences? Does it lack a lot >>of the built-in features of the real chip? >> >>It sounds like you are asking for two different things. First, >>a way to alter the way the compiler generates it's code to >>compensate for the difference in the IP core you are using. > No, that's not what he said. He said they require source to the runtime > libraries. Not everyone works on projects where one is allowed casually > link to binary runtime libraries provided by the vendor. Especially > when CPU resources get tight. > > I use the old 3.07 version of Introl C-11 and have no complaints about > its ability to write good code. Just for kicks compared it to the HC11 > version of GCC many years ago and found GCC severely lacking. Recently > revisited avr-gcc 3.4.3 and found it to be quite impressive. May be > some of the same things which make the AVR version work so well have > found their way into the HC11 version? > > Demo versions of the Introl compilers can be downloaded. Last I looked > the demos were not limited in function, just for "demo or > non-commercial use." Their biggest limitation for Mike is that he has > to have a license for use in a commercial application and hasn't heard > from the owner of the Introl property. > > -- > David Kelly N4HHE, dkelly@dkel... > ======================================================================== > Whom computers would destroy, they must first drive mad. > > > Yahoo! Groups Links

Hi Mike, When I was still writing for the 6811 I developed my own compiler, assembler, linker and library. At 2005-03-28 20:02, Mike Murphree wrote: >I'm working on a project for our company and I need to find an >available C compiler for the 'HC11. Most of the companies we've >talked to have either eliminated their 'HC11 product or sell it >without support. What I'm looking for is recommendations on what a >good and currently available optimizing ANSI C compiler is. The >companies that have a product available that I know about are: > >IAR >Cosmic >Hi-Tech >Metroworks (Hiware) > >We are using an IP core and not a real HC11 so we need access to the C >runtime source (and preferably library). I would demand that anyway. By the way, there used to be a lot of public c-libraries around. And the start-up code of the 6811 is a real no-brainer. >Most of the native HC11 >registers and peripherals are either not supported or implemented >differently so we need to be able to customize the library source if it >depends upon them. Compiler manufacturers should clearly separate the compiler part from the library part. >We are currently using the Imagecraft product and >have exceeded the amount of code space that we would like to use, so >good optimization is a must. The 'problem' with the 6811 code is that it is already so easy to generate compact code for it with relatively little effort (simple compilers) that condensing the code even more is very hard. I'd consider buying parts with more code space. From my compiler experience I have learned that generated 6811 code doesn't have to be more than about 30% more voluminous than hand-coded assembler. And that was before global optimization of code. But in compiler development the problem is: First you optimize all the obvious problems, each increasing the density of the code with 10% or such, but once you are done, you have to double or quadruple the complexity of the compiler to condense the code with a couple of more percents. Not really worth the added risk that the added complexity costs. >We are using the NoICE debugger and it >would be helpful if the object file format was supported by the >compiler/linker. Why do you need a debugger? Sounds like a hardware developer trying to learn to program by pulling the problem into the hardware-realm. Greetings, Jaap

On Mar 28, 2005, at 9:21 PM, Jaap van Ganswijk wrote: > > Hi Mike, > > When I was still writing for the 6811 I developed > my own compiler, assembler, linker and library. I don't have that kind of time... > By the way, there used to be a lot of public > c-libraries around. And the start-up code of the > 6811 is a real no-brainer. It is, but you need to have it, especially if you aren't using a real HC11. On ICC11, the startup code accessed the serial port register. Naturally that was real memory on my board. > Compiler manufacturers should clearly separate the > compiler part from the library part. Should and do are two different things. > The 'problem' with the 6811 code is that it is already > so easy to generate compact code for it with relatively > little effort (simple compilers) that condensing the > code even more is very hard. I'd consider buying parts > with more code space. HC11 isn't that well equipped to handle a C compiler. I'd rather use an AVR but that's not a choice, and this is an IP core, not a real processor. I'm using a full 64K memory map. > > From my compiler experience I have learned that generated > 6811 code doesn't have to be more than about 30% more > voluminous than hand-coded assembler. > > And that was before global optimization of code. > > But in compiler development the problem is: First > you optimize all the obvious problems, each increasing > the density of the code with 10% or such, but once you > are done, you have to double or quadruple the > complexity of the compiler to condense the code with > a couple of more percents. Not really worth the added > risk that the added complexity costs. I've looked at the ICC11 output and there is room for quite a bit of improvement. I haven't found any real compiler errors either though which is important too. The last time that I used a HC11, I only used assembly. Again, I don't have that kind of time now. > Why do you need a debugger? Sounds like a hardware > developer trying to learn to program by pulling the > problem into the hardware-realm. It's mainly a convenience to get the code loaded easily now. The final product won't have one. While I am an accomplished VHDL FPGA designer, I learned to program 16 years before that. I learned VHDL about 11 years ago. That should give you some idea where I am on the experience chart... Mike

On Mar 28, 2005, at 2:07 PM, Robert L. Doerr wrote: > From your post you said that you are using an IP HC11 core > instead of a real 68HC11 and that the core implements things > differently. What are the differences? Does it lack a lot > of the built-in features of the real chip? > > It sounds like you are asking for two different things. First, > a way to alter the way the compiler generates it's code to > compinsate for the difference in the IP core you are using. No, thats not what he said. He said they require source to the runtime libraries. Not everyone works on projects where one is allowed casually link to binary runtime libraries provided by the vendor. Especially when CPU resources get tight. I use the old 3.07 version of Introl C-11 and have no complaints about its ability to write good code. Just for kicks compared it to the HC11 version of GCC many years ago and found GCC severely lacking. Recently revisited avr-gcc 3.4.3 and found it to be quite impressive. May be some of the same things which make the AVR version work so well have found their way into the HC11 version? Demo versions of the Introl compilers can be downloaded. Last I looked the demos were not limited in function, just for "demo or non-commercial use." Their biggest limitation for Mike is that he has to have a license for use in a commercial application and hasn't heard from the owner of the Introl property. -- David Kelly N4HHE, dkelly@dkel... ======================================================================== Whom computers would destroy, they must first drive mad.

Hello Mike, From your post you said that you are using an IP HC11 core instead of a real 68HC11 and that the core implements things differently. What are the differences? Does it lack a lot of the built-in features of the real chip? It sounds like you are asking for two different things. First, a way to alter the way the compiler generates it's code to compinsate for the difference in the IP core you are using. Second, you are looking for a C compiler that will generate more compact code. Are these correct assumptions? For the first item I would ask that question to the supplier of the IP core that you are using. If it is different what tools are normally used to generate code for it? If the compiler you are using can't generate code that will fit can you take another look at the algorithms you are coding in C to deterime if you can do it a shorter way? Take a step back or have someone else take a look. Sometimes a fresh perspective is all that is needed. If all else fails you could look at some of the other programming tools for the 68HC11. Assembly is what I prefer but supposedly there is a Tiny4th and SBASIC compiler for the 68HC11 that may also do the job. Good Luck, Robert Mike wrote: > --- In m68HC11@m68H..., BobGardner@a... wrote: >> >>In a message dated 3/28/05 2:05:19 P.M. Eastern Standard Time, >>mike@t... writes: >> >>IAR >>Cosmic >>Hi-Tech >>Metroworks (Hiware) >> >>====================== >>Imagecraft! > > Okay, that's the second reply that said Imagecraft, but I've already > contacted Richard and they don't offer an optimized version for the > HC11 and we are *already* using Imagecraft as mentioned in the > previous post. > > Mike

--- Mike Murphree <mike@mike...> wrote: > > > IAR > Cosmic > Hi-Tech > Metroworks (Hiware) > > We are using an IP core and not a real HC11 so we need access to the C > runtime source (and preferably library). Most of the native HC11 > registers and peripherals are either not supported or implemented > differently so we need to be able to customize the library source if it > depends upon them. We are currently using the Imagecraft product and > have exceeded the amount of code space that we would like to use, so > good optimization is a must. We are using the NoICE debugger and it > would be helpful if the object file format was supported by the > compiler/linker. > I still use assembly on the HC11 (freeware CrossBow assembler from Persistor Instruments on a Mac). I've heard good things about the Hi-Tech compiler as far as price, code generation size and stability of the development environment but I have only used it on the PIC and that very little. Have you thought about Gnu gcc?? It's free but I have no idea about whether NoICE will work with it. There is a group on Yahoo: http://groups.yahoo.com/group/gnu-m68hc11/ You will get some answers there. It's a fairly active group - 16 new messages in the last 7 days. Regards, Jim Dodd Onset Computer Corp. __________________________________