8 bit microcontroller market
in [Embedded]
|
Prev: Tiny Bootloader
Next: Link&Locate 86?
From: Jim Granville on 8 Sep 2006 00:45 Dave wrote: > On Thu, 07 Sep 2006 22:32:02 +0000, Joerg wrote: > > >>Yep. He who thinks assembler is all stone age has probably never >>programmed an engine control or something like that. There might only be >>milliseconds between loss of loop lock and a destructive detonation, >>pieces raining out of the sky and all that. > > > Interesting example. I started programming in 68K assembly language many > years ago and still use it. Over the last ten years, engine control > software I have written has been sold in probably 15-20 million cars. And > is still being sold. _Very_ little of the software is done in assembly. > Some of the initialization code needing access to processor registers > after power-up is in assembly. Also in assembly is "wrapper" code for one > or two ISRs and none of these dealt with any engine control functions. > The only significant use of assembly is in electronic throttle control > where dual software paths are used. One path is assembly so as to be able > to choose different registers and instructions from the higher-level > language code. The SW which deals with loss of lock from the engine > timing sensor is in the HLL, BTW. ;-) Do you use the TPUs, and if so, how are they coded ? > > A rough count of lines of code for a recent model year (V6 engine) is > > Assembly 4288 2.97% > C 7411 5.13% > Modula-GM 132891 91.91% > ---------------- ------- > Total 144590 Code size footprint for this set of stats ? > > The C code is a recent addition and is used only for CAN communications. That explains the unusual use of 3 languages. > Of the C compilers I have looked at for 68K use (Diab, Metrowerks), none > could generate 68K code to compete with the M-GM compiler. Is the M-GM compiler generally available, or do they keep this in-house. Someone should tell them it would be great PR to open source this ! :) -jg
From: David Ashley on 8 Sep 2006 01:06 Dave wrote: > The C code is a recent addition and is used only for CAN communications. > Of the C compilers I have looked at for 68K use (Diab, Metrowerks), none > could generate 68K code to compete with the M-GM compiler. Are you saying the Motorola 68000 is still being used in stuff these days? I wrote tons of 68000 code for the Amiga. Are there surface mount 68000's? Can you embed the core in with useful peripherals? gcc supports 68000. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architecture
From: John F on 8 Sep 2006 02:22 Yuriy K. wrote: > John F wrote: > >>>>> Necessity to use assembler usually points to the inadequate >>>>> processor selection. >>>> You can't mean what you are saying here. >>> Yes, I can and I do. Assembler is needed in a very few, very >>> special >>> cases. >> >> No. It enables you to do a lot of things on hardware you would have >> tossed and bought something three times more expensive. > > Yes. For typical processor (excluding specialized processors DSP and > peripheral controllers like PIC) C is only 20-30% less effective > than > assembler. Depend on task it may even generate smaller code. 20% less effective can be 40% more expensive... in hardware/power. I'm not willing to do that :-) C has it's place. Sure. Everyday stuff should be done there. But if you ever had to switch to a larger ?C just because of a few bytes of code don't fit into memory, you'll soon learn to use ASM... trust me. >>>> I even write ASM on high >>>> speed DSPs to get the best out of the material. >>> DSP is one of these special cases. >> >> But not the only one. > > No. As usual there are very rare special cases when assembler is > really necessary. As long as they kept rare it is not a problem. No. _Common_ or _frequent_ cases can be made faster/smaller/cheaper. That's whar Amdahl's law is about. >>> And even for DSP assembler should not take a big percentage of the >>> code. >> >> What do you mean? By LOC? By development time? By execution time? > > By the source code size. > > Best optimization is the algorithm optimization. Writing in > assembler > fast interrupt or inner loop could be acceptable as a last resort. My applications spend most of their time in interrupt routines... most of which aren't longer than a few ?s... that's a big problem then. No C is possible. >>>> If you write an >>>> interrupt-routine in C it says that you don't care about timing >>>> at >>>> all. That's it. >>> I write all my interrupt routines in C. It means the proper >>> processor >>> selection and good task division between interrupt and >> >> And? :-) > > And the rest of the software. Minimizing tasks you need to do in the > interrupt is very helpful. Less than 5 lines of ASM is hardly ever possible. Still 80% of time is taken there. >> I have to disagree. Assembler is a very important instrument. If >> you >> aren't able to use it you shouldn't do embedded systems IMHO. > > :) Unfortunately, I did quite a lot of x51 assembly programming. > Just > did not know better at that time. Fortunately, these days were long > ago. They are back! >>>> It shows your ignorance to hard realtime constraints. > > Hard realtime constraints have nothing to do with programming > language. BTW it can be a hard 10 seconds response time. :-P They have! Really. Read the other posts. >>>> Compiler- and optimisation-independent timing is _very_ >>>> important. >>> That's what timers, compare/capture units and other good hardware >>> stuff is used for. >> >> Not at all. You might still introduce nasty glitches in mixed >> signal-designs, phase noise in digital modulation systems if you >> don't equal out conditional branches... > > You can screw up any design in a million different ways in any kind > of > language. I could believe that you have specific constraints in the > particular design. I could not believe that using assembler is the > only solution or even the best solution. It is the only solution. You can't guarantee in C that with every optimisazion you get the same length of execution time. It's just not possible. I don't even do inline assembly because of the prologue and epilogue the compiler adds. You don't have any control over that in C. That's what C is about! It hides this stuff. I don't care to write interfacing code in C or slow serial communication code - but as soon as you try to get Mbit/sec you'll soon switch to ASM again. Especially on slow aka power saving ?Cs... -- Johannes You can have it: Quick, Accurate, Inexpensive. Pick two.
From: John F on 8 Sep 2006 02:25 David Ashley wrote: > Dave wrote: >> The C code is a recent addition and is used only for CAN >> communications. Of the C compilers I have looked at for 68K use >> (Diab, Metrowerks), none could generate 68K code to compete with >> the >> M-GM compiler. > > Are you saying the Motorola 68000 is still being used in stuff these > days? I wrote tons of 68000 code for the Amiga. Are there surface > mount 68000's? Can you embed the core in with useful peripherals? > > gcc supports 68000. Have a look at www.freescale.com :-) Tons of them :-) -- Johannes You can have it: Quick, Accurate, Inexpensive. Pick two.
From: CBFalconer on 8 Sep 2006 01:56
Dave wrote: > .... snip ... > > A rough count of lines of code for a recent model year (V6 engine) is > > Assembly 4288 2.97% > C 7411 5.13% > Modula-GM 132891 91.91% > ---------------- ------- > Total 144590 > > The C code is a recent addition and is used only for CAN communications. > Of the C compilers I have looked at for 68K use (Diab, Metrowerks), none > could generate 68K code to compete with the M-GM compiler. Assuming M-GM is a real Modula system, it should also save you much wailing and gnashing of teeth over silly errors. -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> |