C for embedded controllers (was Re: Timed mechanical fuel injection )

[Dan J. Declerck]

> --------

>    In message <199511220503.XAA06506 at net.dris.com> , you write:

> | going to market it.  It continually is improving, and I agree with Larry,
> | use machine language.  Although something like C is easier to program,
> | machine code is more direct to the point, requires less memory, and the
> | hardware often can be made simpler.  My fuel injection system uses one HC11,

> ok, I don't want to start a debate nor a flame war on this, but some of
> the advantages of *not* using assembly should also be discussed
> (again?).

> | C is easier to program

> Absolutely. From conception to the final debugged program, assembly
> language takes me at least 4 times longer to develope for *small*
> programs (YMMV, the ratio is worse for RISC). Once you get used to
> using a high level debugger, like gdb, its very hard to revert back
> (and unnecessary) to a low level monitor. RTOS, math libraries, and
> other software tools are much more available for C (gnu bin-utilities,
> gcc, gdb, newlib, glibc, RTEMS,... are examples currently ported to
> efi332. Programming efi332 is *no* different than programming under any
> unix system. I've often ran the same program on an SGI workstation,
> linux PC, and efi332 *without* any modifications.).

Yes, but if you use a 68332 to the max of it capabilities, there are MANY
performance mods you can do in assembly that you can't do in C.

Don't get me wrong, I do most of my stuff in C, and use assembly when I
want that extra burst of performance. for example:

	xdef	memcpy
	
memcpy
	movem.l	a0-a1/d0,-(a7)
	move.l	(24,a7),d0	* size
	movea.l	(16,a7),a0	* dest
	movea.l	(20,a7),a1	* src

	subq.l	#1,d0
loop
	move.b	(a1)+,(a0)+
	dbra	loop,d0

	movem.l	(a7)+,a0-a1/d0
	rts



I belive this snippet of code is the fastest memcpy() function on the planet.

I've used this extensively, since it uses loop mode, and
can speed up some time critical operation immensely!
 
> | machine code is more direct to the point

> I don't understand this comment... do not the two programs (C vs
> assembly) do the same thing?


You can't:

Modify the SR in C
Conditionally branch on some overflow conditions in C, either.
Use the Table lookup and interpolate instructions in the CPU32.

> | requires less memory

> True, but maybe only by 10-20% with a good optimizing C compiler (gcc
> for the 68k is a good example. Optimization is cpu dependent.). With
> larger programs it is conceivable the C will be smaller since it
> generally promotes better structure. The archive has examples
> comparing assembly to C for the 68000 (efi68k).

> | hardware often can be made simpler

> This is nonsense. Remember, assembly can easily be placed in-line
> within any C code. Functionally there can be no difference.  Execution
> maybe slightly slower for C in general, but time critical routines can
> be written in assembly.

>                                    John S Gwynne
>                                           Gwynne.1 at osu.edu
> _______________________________________________________________________________
>                T h e   O h i o - S t a t e   U n i v e r s i t y
>     ElectroScience Laboratory, 1320 Kinnear Road, Columbus, Ohio 43212, USA
>                 Telephone: (614) 292-7981 * Fax: (614) 292-7297
> -------------------------------------------------------------------------------

-- 
=> Dan DeClerck                        | EMAIL: declrckd at cig.mot.com      <=
=> Motorola Cellular CSD               |                                  <=
=>"The truth to CDMA... is spreading"  | Phone: (708) 632-4596            <=
----------------------------------------------------------------------------