Devyn wrote:

<snip>

>I want know if what i'm doing is right-
>
>1) Write the code in C
>2) View the assembly version
>3) Cut out extra lines and optimize Assembly Code
>4) Generate Hex code and download it into the PIC

I have no experience with the Hitech compiler nor with PICs, but Step 3
is not typical in any of the many development environments I have used.
The compiler should be responsible for its own optimizations.  Even in
unoptimized mode there should be few if any truly "extra" lines.  The
worst part is that doing this seperates ones source code from the object
code it represents.  This makes development and maintenance far more
difficult.

The only time I have done this kind of thing is when I used C as an
algorithmic starting point for a function that I knew would have to be
extremely optimized for speed.  In this case, only the assembly source
was used in the release build and the C source was included only as
comments in the assembly source to document the technique.

<snip>

-- 
========================================================================
          Michael Kesti            |  "And like, one and one don't make
                                   |   two, one and one make one."
          m...@gv.net            |          - The Who, Bargain

"Albert Lee Mitchell" <a...@albert.amresearch.com> wrote in message
news:p...@albert.amresearch.com...
> On Fri, 19 Dec 2003 00:47:16 +0000, Chris Hills wrote:
>
> > In article <p...@albert.amresearch.com>,
> > Albert Lee Mitchell <a...@albert.amresearch.com> writes
> >>       Linux won't help a bit with embedded micros, move on to the three
or
> >>four
> >>main languages used,
> >
> > C in 90%
>
> Do you have any data to support this guestimate?
>
> >>Basic,
> > only by amateurs at home

I am under the impression that the basic compilers/interpreters are good
tools for people who have an objective but don't want (or can't) get too
deep into the understanding of controllers, etc. Builders of model robots
and the like do pretty well with the parallax stamp. It is also a good
product for mechanical engineers, scientists, etc., who want to accomplish
tasks that are appropriate to those kinds of products without going
overboard in terms of having to learn to program in C or asm. -- Mike

Michael R. Kesti <m...@gv.net> wrote:
> I have no experience with the Hitech compiler nor with PICs, but Step 3
> is not typical in any of the many development environments I have used.
> The compiler should be responsible for its own optimizations.  Even in
> unoptimized mode there should be few if any truly "extra" lines.  The
> worst part is that doing this seperates ones source code from the object
> code it represents.  This makes development and maintenance far more
> difficult.

If you're trying to pass off compiler output as assembly-language
homework, as I suspect the OP might be doing, there probably will be 
"extra lines" ;P

pete
-- 
p...@fenelon.com "There's no room for enigmas in built-up areas."

In article <PzkHb.14738$7D3.3097@fed1read02>, Mike Turco
<m...@yahoo-nospam4me.com> writes
>
>"Albert Lee Mitchell" <a...@albert.amresearch.com> wrote in message
>news:p...@albert.amresearch.com...
>> On Fri, 19 Dec 2003 00:47:16 +0000, Chris Hills wrote:
>>
>> > In article <p...@albert.amresearch.com>,
>> > Albert Lee Mitchell <a...@albert.amresearch.com> writes
>> >>       Linux won't help a bit with embedded micros, move on to the three
>or
>> >>four
>> >>main languages used,
>> >
>> > C in 90%
>>
>> Do you have any data to support this guestimate?

Several sets.

The one below shows C at 80% in 1997... the use of C in embedded work
has not deminished.  BAsIC and PL/M have declined. C++ increased. 

I can dig out other surveys etc but most are in hard copy. this one was
electronic.



http://www.netrino.com/Publications/Bibliography

From: Bill Giovino <e...@microcontroller.com>
Subject: Re: Embedded Systems development languages?
Date: Sat, 04 Sep 1999 
Organization: http://www.Microcontroller.com

Re: Embedded Systems development languages?

That has a one-letter answer:  C.  I would guess 75% of small-to-medium-
scale projects are done largely in C, occasionally with small hand-coded
sections of assembler.  Another 20% in assembler and Forth, and the rest
in obscure languages for certain esoteric applications.  Programmers
often claim to write these programs in C++ but their coding style is
generally just 'straight C'; they just happen to be using a C++
compiler.  A bigger project, running on PC-like hardware, is a different
animal and genuine object-oriented C++ Would probably be the language of
choice.  A very small project (less than about 1K of code) will more
frequently be written in assembler, purely because the processor it's
running on will be so small that hand-optimisation will be necessary.

This information is from 1997:
Programming Languages used in Embedded Development:
C                       80%
Assembly        75%
C++             49%
BASIC           15%
Fortran         8%
ADA             6%
Java            4%
Forth           1%
PL/M            1%
Other           2%

This is from a representative survey of 233 software engineers over
various markets. Note that this does not add up to 100%, as more than
one language may be used on a project...  Embedded C++ was not broken
out from C++.

Many surveys ask engineers what language they would be using 2, 3 years
out. In my opinion, those numbers are worthless - any engineer will tell
you he hopes to be hopes to be using the latest programming language!
80% of you are using fuzzy logic, right?


-Bill Giovino
 http://www.Microcontroller.com




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

"Chris Hills" <c...@phaedsys.org> wrote in message
news:XoOqFDADbf7$E...@phaedsys.demon.co.uk...
> In article <PzkHb.14738$7D3.3097@fed1read02>, Mike Turco
> <m...@yahoo-nospam4me.com> writes
> >
> >"Albert Lee Mitchell" <a...@albert.amresearch.com> wrote in message
> >news:p...@albert.amresearch.com...
> >> On Fri, 19 Dec 2003 00:47:16 +0000, Chris Hills wrote:
> >>
> >> > In article <p...@albert.amresearch.com>,
> >> > Albert Lee Mitchell <a...@albert.amresearch.com> writes
> >> >>       Linux won't help a bit with embedded micros, move on to the
three
> >or
> >> >>four
> >> >>main languages used,
> >> >
> >> > C in 90%
> >>
> >> Do you have any data to support this guestimate?
>
> Several sets.

That wasn't my question and I doubt that you and I would have any
disagreement regarding this matter. I don't doubt what you are saying about
C being the prevalent language. It beats basic, hands down, when it comes to
doing serious work with controllers. However, there are many instances where
C is not required. Basic is a good general purpose tool that bridges the gap
for people who aren't necessarily f/w or h/w folks, but need to accomplish
specific tasks.

You will find articles about real-time and embedded software design
at:

http://www.eventhelix.com/RealtimeMantra/

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - Go Beyond UML Use Case and Sequence Diagrams

On Fri, 26 Dec 2003 10:36:31 +0000, Chris Hills wrote:

> In article <p...@albert.amresearch.com>,
> Albert Lee Mitchell <a...@albert.amresearch.com> writes
---------snip------------
>>>>Basic,
>>> only by amateurs at home
>>
>>       Correct me if I'm wrong but the original post this thread responds to is
>>by a self-professed amateur. 
> 
> So? That is no reason to use it. There are plenty of C tools and support
> available from the free to the very expensive.  The point is that there
> is a LOT of support for C for all levels. There is no need to tie one
> self down to a less appropreate language just because some ametures use
> it.. 

	Yes, it is a reason unless you are pursuing your own agenda.  The
gentleman originating this tread asked specifically for "amateur" help.  C
is not for amateurs and arguably not for low-level embedded applications. 
At least not with optimization turned on.

>>       On most micros however there is no correlation between the number of 
>>developers using Forth 
>>and the number of embedded control projects in use.
> 
> This is true. The amount of forth in use probably dwindles even more if
> you look ate the number of projects or indeed the number of installed
> devices.

	Dogma again.  Forth is a well-hidden trade secret by most of my clients. 
There is no way, again, that you can supply any meaningful statistics so
please discriminate between your opinion and reality.
 
> I have nothing against forth but an ammeter will get fat more help and
> support (and tools) on a far wider variety of micros and application
> types that he could from forth.

	Huh?  No tool is better than it's user.  Again, the number of products
has no correlation to it's quality.  Hmmm, a pattern is emerging here. 
Instead of pushing your agenda why not give cites and evidence and let the
reader and original poster decide?


-- Regards, Albert
----------------------------------------------------------------------
AM Research, Inc.    			  The Embedded Systems Experts
http://www.amresearch.com          			  916.780.7623
----------------------------------------------------------------------

Albert Lee Mitchell wrote:


>  
>> I have nothing against forth but an ammeter will get fat more help and
>> support (and tools) on a far wider variety of micros and application
>> types that he could from forth.
> 
> Huh?  No tool is better than it's user.  Again, the number of products
> has no correlation to it's quality.  Hmmm, a pattern is emerging here.
> Instead of pushing your agenda why not give cites and evidence and let the
> reader and original poster decide?
> 

I think you miss his point.  I suspect he means the number of *users* who
can provide support via forums like this is greater.

Ian

In article <p...@albert.amresearch.com>,
Albert Lee Mitchell <a...@albert.amresearch.com> writes
>> So? That is no reason to use it. There are plenty of C tools and support
>> available from the free to the very expensive.  The point is that there
>> is a LOT of support for C for all levels. There is no need to tie one
>> self down to a less appropreate language just because some ametures use
>> it.. 
>
>       Yes, it is a reason unless you are pursuing your own agenda.  The
>gentleman originating this tread asked specifically for "amateur" help.  C
>is not for amateurs 

That is not true.... C is taught to 16 year olds at school.  C can be
used by anyone.  In fact one "amateur" I know is on the ISO C working
group.

>and arguably not for low-level embedded applications. 
>At least not with optimization turned on.

Then you are disagreeing with a LOT of professionals who use it for all
sorts of work including safety critical and medical from 8051's and Pics
upwards. 


>>>       On most micros however there is no correlation between the number of 
>>>developers using Forth 
>>>and the number of embedded control projects in use.
>> 
>> This is true. The amount of forth in use probably dwindles even more if
>> you look ate the number of projects or indeed the number of installed
>> devices.
>
>       Dogma again.  Forth is a well-hidden trade secret by most of my clients. 

Not that you have a hidden agenda for going against the majority of
professionals and ammeters who use C.

I don't  suppose you are commercially involved with Forth and Basic
tools?

>There is no way, again, that you can supply any meaningful statistics so
>please discriminate between your opinion and reality.

I can dig them out... (again)  I think it was 80% using C and Forth and
Basic around 10% about 5 years ago. 

Basic usage has dropped (as have the number of supported tools) Forth?
You would know about that better than I as it is YOUR agenda but I would
bet it is not gaining in market share.


>> I have nothing against forth but an ammeter will get fat more help and
>> support (and tools) on a far wider variety of micros and application
>> types that he could from forth.
>
>       Huh?  No tool is better than it's user.
This is true.

>  Again, the number of products
>has no correlation to it's quality. 

Correct but in a large number of products there will be good ones and
cheap ones and good cheap ones and probably several that are just right
for you with a large users base you can cal on for help.

Where there is a choice of 2 or 3 with a small(er) user base the choices
are far more limited. Also with fewer users the tools tend to get less
usage and testing. 

> Hmmm, a pattern is emerging here. 
>Instead of pushing your agenda why not give cites and evidence and let the
>reader and original poster decide?

Please do. It appears you have an agenda of pushing a language you
support commercially.  Lets throw it open. How many forth tools and
users are there out there?

>----------------------------------------------------------------------
>AM Research, Inc.                        The Embedded Systems Experts
>http://www.amresearch.com                                916.780.7623
>----------------------------------------------------------------------

I don't suppose you represent a company that is pushing forth  and basic


?


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

On Thu, 1 Jan 2004 10:51:41 +0000, Chris Hills <c...@phaedsys.org>
wrote:

>Basic usage has dropped (as have the number of supported tools) Forth?
>You would know about that better than I as it is YOUR agenda but I would
>bet it is not gaining in market share.
...
>It appears you have an agenda of pushing a language you
>support commercially.  Lets throw it open. How many forth tools and
>users are there out there?

My company, MicroProcessor Engineering Ltd. (MPE), is a vendor
of Forth tools. We've been in business since 1981. Other Forth
vendors include Forth Inc, Triangle Digital, and New Micros.
MPE's clients make mobile phones, plan the construction of
airports, make mass spectrometers, access control systems
and telephone PABXs. Like all of the smaller compiler vendors,
we do a great deal of consultancy work. The bulk of our sales
is to professional programmers, but we do have 8051 tools
including hardware at around the GBP 64 (USD 100) price point.

Commercially, C is the equivalent of English among spoken
languages: it may not be the best, but it is the common language.
One day English may give way to another language.

In the programming world, all languages other than C/C++ have
declined in popularity with the exception of Java. Among the
minority languages, Forth is doing surprisingly well. I only
got into Forth because I was looking for a portable Pascal
compiler. Where are Eiffel and Modula 2 now? I really liked
Modula 2.

As I see it, there are three major areas for tool chains:
PCs; PDAs; and deep embedded. Traditionally Forth's strength
has been in deep embedded. These days, Forth compilers produce
optimised native code. The older threaded implementations
are obsolete except where code density is the overriding
objective. Forth can be classified as an interactive and
extensible language.

Where Forth scores is when you take advantage of interactive
development on the target. At the end of 2002, MPE was
involved in a bomb disposal machine project. The real
problems were in the mechanics and drives. Interactive
experiments wth the system gave us numbers about the world
we were controlling. Yes, those experiments could have been
obtained using C, but it would have taken very much longer.

For similar reasons, I find it much easier to explore the
Windows API from Forth than from C.

During the Europay Open Terminal Architecture project, an
OTA payment terminal program written in Forth was rewritten
in C. The target was an 8051. The Forth system occupied
32k bytes total including all O/S and hardware drivers.
The Keil 8051 C compiler exceeded 64k before all files were
linked. The C programmer was an excellent programmer and had
access to the Forth sources.

Our PowerNet TCP/IP stack with multi-threaded Telnet and
web servers (with CGI and ASP) on most CPUs fits into 112kb
including all the hardware drivers.

When you take advantage of Forth's interaction and
extensibility, you have a system that produces compact and
fast code. The proliferation of scripting languages for
desktop PCs shows that there are things that C does not
do well. Forth is one of those languages that is much
better than C in some areas. One size does not fit all.

Stephen

--
Stephen Pelc, s...@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads