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

>> 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.

Back then (1982 or so) Verilog wasn't an option, and we did do
most of our 1K ROM 60 bytes of RAM apps in assembly.

However, the 8051 family has grown up (somewhat painfully) over
the past 20 years and now has varieties with 128+ KB of ROM and
8+ KB of RAM.  When you get to apps of that size, writing the
whole thing in assembly is pretty painful.

-- 
Grant Edwards                   grante             Yow!  Do I hear th'
                                  at               SPINNING of various
                               visi.com            WHIRRING, ROUND, and WARM
                                                   WHIRLOMATICS?!

Klaus Vestergaard Kragelund wrote:

>
snip

>>
>> 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
> 
>

Unfortunately Ansi C compliance does not help when switching micro platform
as all the important stuff like interrupts, timers, peripherals etc are all
different.

Ian

Walter Banks wrote:
> 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.
> 

I'm unaware of any public domain C compilers. Do you have an example?

[...]

Spehro Pefhany wrote:

> 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).
> 

Was?  What do they use now?

Ian

I think you need to look at your posting line length options...

On Tue, 06 Jan 2004 13:32:06 -0500, Walter Banks
<w...@bytecraft.com> wrote:

>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.

I've used NQC compilers for several micros, including Keil's excellent
C51 and CCS's adequate PIC C.  I prefer either to programming in
assembly.

I'm not sure what you mean by "public domain C compilers."  Perhaps
avr-gcc (which isn't really public domain, but let's skip that
discussion for now)?  That actually works quite well.  Certainly much
closer to real C than (e.g.) Keil C51 (though it still struggles with
the Harvard architecture).  SDCC?  I haven't tried that yet, so I
can't really comment.

>
>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 

True.  Given

   unsigned char x, y, z;

   x = y+z;

the compiler _should_ be able to avoid generating a 16-bit add
operation.  I don't recall any that do so, however.  Except for a NQC
compiler for AVR.  However, that compiler that has other bugs.  Such
as, when given

   unsigned int n;
   unsigned char s = 12;

   n = 1 << s;

it will write a zero to n.  

>> 
>> 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.

Section 5.2.4.1 says an implementation must be able to translate _and_
_execute_ a program containing at least one instance of each limit.
Hard to execute programs when the resources aren't there.

>
>> 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. 

True to a point.  I guess my particular complaint is that, unless
special extended keywords are used, Keil C51 will generate
non-reentrant functions which cannot be called recursively.  There are
good reasons for this.  And the reasons have to do with the
architecture of the 8051 and its memory hierarchy.  But it's not C.

>> 
>> 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.

I'd heard of this, and am interested in seeing the results.
Obviously, though, it's not C yet, and certainly no compiler (free or
expensive) implements those today.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Ian Bell wrote:

> Spehro Pefhany wrote:
> 
> 
>>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).
>>
> 
> 
> Was?  What do they use now?

The *was* refers to the *archtypical application*
and was not meant to infer that it is no longer
used in IBM PC keyboards.

It's been a few years since I've disassembled an
IBM keyboard and I don't rightly know what kind
of controller it uses.

Dave Hansen wrote:
> 
> I'm not sure what you mean by "public domain C compilers."

Public domain in the sense that they are widely available (some 
times with usage restrictions) to port C to new target platforms. 
Some examples are the portable C compiler and GCC which have 
been used for this. All of the compilers of this type that I 
am familiar with were not originally intended for non hosted 
or limited resource targets.

> Section 5.2.4.1 says an implementation must be able to translate _and_
> _execute_ a program containing at least one instance of each limit.
> Hard to execute programs when the resources aren't there.

This could trigger a huge thread by itself. In general if the 
intention is to validate the compiler limits then selective 
family members, simulation or external user defined memory 
space (ISO/IEC WDTR 18037) can be used to achieve the test. 
> 
>
> >> 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 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.
> 
> I'd heard of this, and am interested in seeing the results.
> Obviously, though, it's not C yet, and certainly no compiler 
> implements those today.

ISO's mandate is to create standards that reflects current 
practice. The ISO/IEC WDTR 18037 technical report examined 
in detail Byte Craft, ACE, Keil, Cosmic, HiWare and a bunch 
of others. There is a lot of collective compiler experience 
in all of the topics in the report.

You are correct it is not C yet. It is a Technical Report 
that describes changes to the language in the future, a 
kind of language Beta test.

Walter Banks
http://www.bytecraft.com

Morris Dovey wrote:

> 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.

Hey, I cut my programming teeth on a desktop computer with a Z80 
processor in. It had word processors, development tools, an OS, games, 
and everything :-)

I even had a mouse for it, and a light pen...

ABS

Walter Banks wrote:
> 
> Dave Hansen wrote:
> 
>>I'm not sure what you mean by "public domain C compilers."
> 
> 
> Public domain in the sense that they are widely available (some 
> times with usage restrictions) to port C to new target platforms. 
> Some examples are the portable C compiler and GCC which have 
> been used for this. All of the compilers of this type that I 
> am familiar with were not originally intended for non hosted 
> or limited resource targets.
> 
[...]

I've never heard of the portable C compiler, but GCC is definitely
not PD. SDCC, which is intended for micros, is perhaps not ready
for prime time, but is definitely not PD.

I'm aware of nothing in the computer realm worth 2 bits that is
PD. Never confuse a free license with PD.

Albert Lee Mitchell said...

> 	Third, C is essentially impossible to debug without a In Circuit
> Emulator.  

I guess I've been dreaming for the last 10 years then.  Shipped at 
least fifteen products and never used an ICE.


Casey