On 2004-01-07, CBFalconer <c...@yahoo.com> wrote:

>> 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.
>
> The 8080 was no more primitive than the Z80,

I'd have to disagree.  Geeze, the 8080 required _three_ supply
voltages (+5, -5, and +12 IIRC).  The Z80 only required a
single 5V supply.  That was a huge advance.  The clock
circuitry on the Z80 was also much better and didn't require a
high-voltage dual-phase clock generator chip.  All you needed
was a single phase 5V TTL clock signal.

The Z80 interrupt model was far, far superior to Intel's crappy
hack which required an external interrupt controller in the
form of an 8059 (a horrible mistake which we're unfortunately
still stuck with).  

The Z80's dual register banks also made interrupt handling or
coroutines on the Z80 much easier than on the 8080.

The Z80 had built-in refresh circuitry for dynamic RAM.  With
the 8080, you had to add a dynamic RAM controller chipset.

All told, the Z80 eliminated the need for two power supplies
and about a half-dozen not-very-cheap support chips.

The addition of two 16-bit index registers also made for far
superior code generation for high-level languages.  There were
80 new opcode that included block move and block I/O
instructions.

And it just plain ran a hell of a lot faster.

IOW, the Z80 completly kicked the 8080's arse.  Once the Z80
came out the 8080 completely vanished from new designs.  The
8085 was a very lame, late, and failed attempt at meeting the
challenge of the Z80.

-- 
Grant Edwards                   grante             Yow!  I'm RELIGIOUS!! I
                                  at               love a man with a
                               visi.com            HAIRPIECE!! Equip me with
                                                   MISSILES!!

On Tue, 6 Jan 2004 21:12:10 -0600, Casey wrote:

> 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

This is interesting. I've never thought about it before, but I've done
dozens of microcontroller based projects and I've never used an ICE either.

Bob

CBFalconer wrote:
> David Brown wrote:
> 
> ... snip ...
> 
[...]

> 
> As an example, I could create a new machine, either in hardware or
> as a simulator, copyright/patent/whatever that, and adapt gcc to
> generate code for it.  I get the useful software to promulgate my
> ideas for essentially nothing, or at least a minimum of my
> effort.  I retain complete ownership of the machine, the right to
> charge whatever I wish for it, but NOT the right to hide or
> restrict use of my gcc mods.
> 

This approach has been used effectively by Intel and Axis, especially
Axis, whose whole processor business depends on GCC and Linux.
For Intel, it allows them to get real world performance numbers on
new processors many times faster than otherwise possible.

It is rarely not in a hardware company's interest to support open
tools that support their products.

The point I was making at the start of the thread was GCC and some of the
similar compiler
technology bases were not designed for non_hosted embedded systems
environments. These
compilers are far from state of current compiler art and have a
performance down side for many
developers, silicon companies  and applications developers.

The compiler is free and so are the sources but Gillette also sent me a
free razor in
the mail the other day.

Maintenance and support costs are high either for the individual, company
from a third party.

The problem for small embedded processors using this type of compilers is
code size and cycle
counts. Promising new architectures are often ignored because of apparent
performance, power
and EMI issues.

- Cycle counts to execute an application in small embedded processors is
with few
   exceptions a function of code size.
- Clock speed requirements depend on cycle counts for the application
timing restrictions.
-  Power ,EMI problems (and FCC approvals) in most small processors based
products
   has almost a direct relationship with clock speed.

Walter Banks
http://www.bytecraft.com

Bryan Hackney wrote:

> This approach has been used effectively by Intel and Axis, especially
> Axis, whose whole processor business depends on GCC and Linux.
> For Intel, it allows them to get real world performance numbers on
> new processors many times faster than otherwise possible.
>
> It is rarely not in a hardware company's interest to support open
> tools that support their products.

On Wed, 07 Jan 2004 15:32:17 +0000, Bob Stephens wrote:

> ----------snip------------ 
> This is interesting. I've never thought about it before, but I've done
> dozens of microcontroller based projects and I've never used an ICE either.
> 
> Bob

	Nor have I but the original statement was that it is essentially
impossible to debug C without an ICE.  Perhaps I should have been more
wordy and broken it into two, how do you step through a C program without
an ICE and how do you debug C?
 
-- Regards, Albert
----------------------------------------------------------------------
AM Research, Inc.    			  The Embedded Systems Experts
http://www.amresearch.com          			  916.780.7623
----------------------------------------------------------------------

Walter Banks wrote:
> The point I was making at the start of the thread was GCC and some of the
> similar compiler
> technology bases were not designed for non_hosted embedded systems
> environments. These
> compilers are far from state of current compiler art and have a
> performance down side for many
> developers, silicon companies  and applications developers.
> 

SDCC was started as a compiler technology for micros. I had to abandon it
a couple of years ago because bugs prevented me from getting the job done,
and I was under time pressure than kept me from working on it myself. I'm
not sure I would have anyway, because I don't care to learn the instructions
to the point of being able to work on a compiler.

A couple of years is a long time, so I don't know what's been improved in the
way of 8051 code generation, but one of these days, there is no reason it will
not be identical quality to any compiler at any price.

Open projects tend not to have timelines and deadlines. There are many different
itches that are scratched by working on open projects, and I mentioned the
rationale for a chip vendor to have good quality tools, libre or not. Why
would a chip vendor, say Cygnal, care if SDCC produced code of equal quality
to Keil? That would be a good thing, probably, but there are so many 8051 vendors
that a single one might not care to have good libre tools. Private architectures
(e.g. AVR and Axis) benefit greatly by having free tools. The chip vendors do
almost all the work. It's not some corps of underemployed hobbyists that decide
to do a GCC port.

> The compiler is free and so are the sources but Gillette also sent me a
> free razor in
> the mail the other day.
> 

I don't follow. You will use up the razor and throw it away. They want you
to buy more.

> Maintenance and support costs are high either for the individual, company
> from a third party.
> 

A person's time will always (I hope) be of value.

There is a healthy business of selling tools to embedded developers, and this
may continue for a long time. It certainly will for FPGAs, because of the
obscure and closed nature.

As I mentioned in an email, GPL code is all that stands between Microsoft and
eternity. They have destroyed everything else. The translation of the GPL
world view to the embedded world will never be perfect or complete, but
developers should understand what this is all about. GPL is not about taking
money and jobs away from people. If Microsoft wanted your market, they would
buy you or destroy you, but they would have it. They cannot touch GPL'd code,
and if you can figure out how to incorporate such in your business, you may
prosper. At a minimum, you can use GPL'd code to your last day.

The GPL does protect "users" against "vendors", and there are many vendors
around here who perceive this as bad, and that's just the way it is. But
the embedded world is diverse and different from the world that created
the GPL. In fact, I think Stallman is on record as saying that he does not
care about the embedded world, since the software is tied so closely to the
hardware as to be virtually inseparable. I think many people see it this way,
and the place for libre tools targeted at micros is still mainly
for hobbyists, and may stay that way.

(As others mentioned, there are many licenses, but the GPL is the prototype).

[...]

On 2004-01-07, Albert Lee Mitchell <a...@albert.amresearch.com> wrote:

>> This is interesting. I've never thought about it before, but I've done
>> dozens of microcontroller based projects and I've never used an ICE either.
>
> 	Nor have I but the original statement was that it is essentially
> impossible to debug C without an ICE.  Perhaps I should have been more
> wordy and broken it into two, how do you step through a C program without
> an ICE

Debug stub and a serial port.  I'm doing it right now on an
H8: burn gdb stub in to flash, and away you go.  Downloading is
a bit slower than traditional ICE, but it works quite well.

> and how do you debug C?

See above.

-- 
Grant Edwards                   grante             Yow!  Intra-mural sports
                                  at               results are filtering
                               visi.com            through th' plumbing...

On Wed, 07 Jan 2004 11:31:53 -0800, Albert Lee Mitchell wrote:

> On Wed, 07 Jan 2004 15:32:17 +0000, Bob Stephens wrote:
> 
>> ----------snip------------ 
>> This is interesting. I've never thought about it before, but I've done
>> dozens of microcontroller based projects and I've never used an ICE either.
>> 
>> Bob
> 
> 	Nor have I but the original statement was that it is essentially
> impossible to debug C without an ICE.  Perhaps I should have been more
> wordy and broken it into two, how do you step through a C program without
> an ICE and how do you debug C?
>  
> -- Regards, Albert
> ----------------------------------------------------------------------
> AM Research, Inc.    			  The Embedded Systems Experts
> http://www.amresearch.com          			  916.780.7623
> ----------------------------------------------------------------------

I debug C the same way I debug assembler or anything else. By writing debug
code. I also like to generate "life noises" like toggling a port bit on
entry to an ISR saying " I made it this far", also squirting out diagnostic
messages to a serial port.

Bob

Bob Stephens said...

> I debug C the same way I debug assembler or anything else. By writing debug
> code. I also like to generate "life noises" like toggling a port bit on
> entry to an ISR saying " I made it this far", also squirting out diagnostic
> messages to a serial port.

I like to toggle test points and watch those on an oscilloscope.  
I monitor events and the duration of interrupt routines this way.


Casey

On Wed, 07 Jan 2004 21:40:55 +0000, Bob Stephens wrote:

> On Wed, 07 Jan 2004 11:31:53 -0800, Albert Lee Mitchell wrote:
> 
>> [quoted text muted]
> 
> I debug C the same way I debug assembler or anything else. By writing debug
> code. I also like to generate "life noises" like toggling a port bit on
> entry to an ISR saying " I made it this far", also squirting out diagnostic
> messages to a serial port.
> 
> Bob

	That's not unsimilar to our methodology except we use the same code as
the finished job will, not test code.  Using the serial port for
diagnostic messages has a major impact on execution speed which I very
much wish to avoid.

	Without running the same code at the same speed you're not really
exercising the final product.
 
-- Regards, Albert
----------------------------------------------------------------------
AM Research, Inc.    			  The Embedded Systems Experts
http://www.amresearch.com          			  916.780.7623
----------------------------------------------------------------------