Graeme Faelban <R...@netscape.net> wrote:

> Keil C51 has a number of 8051 specific extensions, which will require 
> rework when migrating to a different processor.

You're missing an important point, there. Just because Keil *has*
those extensions doesn't mean you have to use them all over the place,
thus making the code unportable.  There'll obviously be some parts of
a project where that will be unavoidable, but those would be the ones
that 100% platform-specific by definition, regardless of how you do
them.

And even where you do use those extensions, you can still hide them
nicely behind some macros, so all it takes to render the code entirely
portable is to change the definition of those.

-- 
Hans-Bernhard Broeker (b...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

On Tue, 06 Jan 2004 16:29:08 +0000, Dave Hansen wrote:
> -----------------snip----------------
>                                -=Dave

	Thanks for adding some more recent experience, Dave, mine is woefully out
of date and I'd forgotten a few of those glitches.  C was written for
Unix, not for 8-bit micros.  Although time has extended C to other venues
and added new features it remains unsuited for the 8051.

	One point, I know you were joking but the 8051 was first designed about
1975 with no thought to C.  I think the languages of the day were first
Assembler (duh), PLI, then Basic.
 
-- Regards, Albert
----------------------------------------------------------------------
AM Research, Inc.    			  The Embedded Systems Experts
http://www.amresearch.com          			  916.780.7623
----------------------------------------------------------------------

Dave,

Modern compiler technology overcomes the majority of the objections to C running on 8 Bit micro's and other small
processors or processors with unusual architectures.

It is unfortunate that many of the C compilers that are currently offered for embedded systems were re-targeted from
public domain C compilers originally implementations for much larger hosted processors. Very good conforming C compilers
have be written
for many of small processors including processors like the 8051's and Microchip PIC's by designing the compiler for the
intended target and utilizing current compiler technology on powerful personal computers.

Dave Hansen wrote:
> 
> 1) C assumes 16 (or more) bit calculations are efficient.  The "int"
> type is supposed to have the width "natural" to the processor, but
> must be at least 16 bits wide.  There is _no_ way in C to to write an
> uncast expression containing at least one operator whose result is
> either {[un]signed] short or [[un]signed] char.

C99 brought forward size specific declarations. The As-If implementation rules allow very efficient expression
implementations (including 8 bit) on small embedded system processors 
> 
> 2) C assumes minimum resources are available.  For example, there must
> be a minimum of 511 identifiers allowed within a block scope.  And 127
> parameters to a function.  And 4095 characters in a string literal.
> and 1023 members in a structure.  Try that with 128 bytes of data RAM.
 
These are translation limits for the compiler. There is no place in the standards that I know of that defines hardware
limits.

> 3) Functions must be able to be called recursively, including main.

There is nothing in embedded micro's that prevents recursive calls. Probably what is more important is there is nothing
in the standard that prevents compilers from optimizing out recursive calls if they are not needed. In the same way
there is no reason
that every function be called in the same way. 
> 
> 4) C has no concept of separate memory spaces, let alone separate RAM
> spaces (data, idata, xdata).  This is bad enough on a von Neumann
> architecture, but on a Harvard micro (like the 8051) it's devastating.

ISO since the release of C99 focussed on C standards for embedded systems to address the specific issues of using C to
program embedded systems. It defines support for multiple address spaces, register access, fixed point data types,
asymmetrical I/O
devices. The result of this work is a Technical Report (ISO/IEC WDTR 18037 Programming languages, their environments and
system software interfaces — Extensions for the programming language C to support embedded processors) that is expected
to become part
of the language in future language standard releases.

Walter Banks

In article <3ffaaf20$0$9719$e...@dread14.news.tele.dk>, Klaus
Vestergaard Kragelund <k...@hotmail.com> writes
>
>"Ian Bell" <i...@ruffrecordsDOTworldonline.co.uk> wrote in message
>news:3...@mk-nntp-1.news.uk.worldonline.com...
>> Klaus Vestergaard Kragelund wrote:
>> C is platform dependant too when it comes to samll 8 bit micros.
>>
>
>Well, I use Keil and that one is ANSI C compliant. And if you need to switch
>then choose a compiler that too is ANSI C compliant or close to that effect

There are many extension in Keil C51 which are not the same in other
8051 C compilers. you will have to do some porting between ANY 8051
compiler let alone 8051 and another target..  However it is MUCH easier
than porting assembler and C is much faster to write and test. 



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ c...@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <bteph5$sul$5...@nets3.rz.RWTH-Aachen.DE>, Hans-Bernhard Broeker
<b...@physik.rwth-aachen.de> writes
>Graeme Faelban <R...@netscape.net> wrote:
>
>> Keil C51 has a number of 8051 specific extensions, which will require 
>> rework when migrating to a different processor.
>
>You're missing an important point, there. Just because Keil *has*
>those extensions doesn't mean you have to use them all over the place,
>thus making the code unportable.  There'll obviously be some parts of
>a project where that will be unavoidable, but those would be the ones
>that 100% platform-specific by definition, regardless of how you do
>them.

Due to the 51 memory map much of it will use the extensions. However it
is not that difficult to change them when porting. 

>And even where you do use those extensions, you can still hide them
>nicely behind some macros, so all it takes to render the code entirely
>portable is to change the definition of those.

I have found that portability comes a LONG way behind reliability,
efficiently and compactness.


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ c...@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Albert Lee Mitchell wrote:

> 	Thanks for adding some more recent experience, Dave, mine is woefully out
> of date and I'd forgotten a few of those glitches.  C was written for
> Unix, not for 8-bit micros.  Although time has extended C to other venues
> and added new features it remains unsuited for the 8051.
> 
> 	One point, I know you were joking but the 8051 was first designed about
> 1975 with no thought to C.  I think the languages of the day were first
> Assembler (duh), PLI, then Basic.

In 1975 nearly all embedded programming was being done in 
assembly language, with FORTRAN and PL/M to follow. There were 
some fairly compact BASIC interpreters; but their performance was 
generally 'poor' to 'intolerable' for time-critical applications.

I used C on (first) I8080 and (later) Z80 CPUs and had no serious 
problems - though I was constrained to integer math. Even the 
primitive 8080 could be programmed to produce 32-bit (or larger) 
results when needed.

I've never needed to produce code for an 8051 (nearly all of my 
more recent work has been on 16- and 32-bit SOCs) but I'm amazed 
to hear that the 8051 has less capability that Intel's old I8080 
or Zilog's Z80!

-- 
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

On 2004-01-06, Morris Dovey <m...@iedu.com> wrote:

> I've never needed to produce code for an 8051 (nearly all of my 
> more recent work has been on 16- and 32-bit SOCs) but I'm amazed 
> to hear that the 8051 has less capability that Intel's old I8080 
> or Zilog's Z80!

Why?  The 8051 (and it's predecessor the 8048) was aimed at
much smaller, simpler applications than the 8080/Z80 family.

IIRC, the 8048/8051 were built for Ford.  They were intended
for very small, simple automotive control applications with a
few KB of code and maybe 50-100 bytes of RAM.  The 8080/Z80 was
a much more "powerful" general-pupose CPU with a stack pointer,
16-bit operations, and everything.

-- 
Grant Edwards                   grante             Yow!  What I want to find
                                  at               out is -- do parrots know
                               visi.com            much about Astro-Turf?

Grant Edwards wrote:

> On 2004-01-06, Morris Dovey <m...@iedu.com> wrote:
> 
> 
>>I've never needed to produce code for an 8051 (nearly all of my 
>>more recent work has been on 16- and 32-bit SOCs) but I'm amazed 
>>to hear that the 8051 has less capability that Intel's old I8080 
>>or Zilog's Z80!
> 
> 
> Why?  The 8051 (and it's predecessor the 8048) was aimed at
> much smaller, simpler applications than the 8080/Z80 family.
> 
> IIRC, the 8048/8051 were built for Ford.  They were intended
> for very small, simple automotive control applications with a
> few KB of code and maybe 50-100 bytes of RAM.  The 8080/Z80 was
> a much more "powerful" general-pupose CPU with a stack pointer,
> 16-bit operations, and everything.

The archtypical application for an 8048 in those
days was a keyboard controller.  I believe the
original IBM PC keyboard used one.

Grant Edwards wrote:

> On 2004-01-06, Morris Dovey <m...@iedu.com> wrote:
> 
>>I've never needed to produce code for an 8051 (nearly all of my 
>>more recent work has been on 16- and 32-bit SOCs) but I'm amazed 
>>to hear that the 8051 has less capability that Intel's old I8080 
>>or Zilog's Z80!
> 
> Why?  The 8051 (and it's predecessor the 8048) was aimed at
> much smaller, simpler applications than the 8080/Z80 family.
> 
> IIRC, the 8048/8051 were built for Ford.  They were intended
> for very small, simple automotive control applications with a
> few KB of code and maybe 50-100 bytes of RAM.  The 8080/Z80 was
> a much more "powerful" general-pupose CPU with a stack pointer,
> 16-bit operations, and everything.

Thanks. I'd never really thought of the 8080 or Z80 as being 
"powerful" engines - and I can't help but grin at your "and 
everything" comment.

I like C (and consider it to be one of the most powerful 
development tools ever) but have to admit that for control 
applications maxing out at few KB of code and 100 bytes of RAM, I 
probably wouldn't consider anything other than Verilog or 
assembly language solutions.
  --
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

On Tue, 06 Jan 2004 11:52:08 -0800, the renowned Jim Stewart
<j...@jkmicro.com> wrote:

>The archtypical application for an 8048 in those
>days was a keyboard controller.  I believe the
>original IBM PC keyboard used one.

That was a variant (8042 or something like that). 

Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
s...@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com