David Brown wrote:

> 
> "Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> wrote in message
> news:4028fe8d_1@mk-nntp-1.news.uk.worldonline.com...
>> Al Borowski wrote:
>>
>> > Ian Bell wrote:
>> >> David Brown wrote:
>> >>
>> >>
>> >>>If there are exceptions, then it is not a rule.  The common opinion
> among
>> >>>PHBs is that C is "easier" than assembly, and therefore every embedded
>> >>>project should be written in C and not assembly.
>> >>
>> >>
>> >> Forgive my ignorance but what is a PHB??
>> >
>> > Pointy-Haired-Boss - The moronic manager from dilbert.
> http://dilbert.com
>> >
>> > Al
>>
>> AH, now I understood.  Never did get into Dilbert.
>>
>> Ian
> 
> "The Dilbert Principle" should be required reading for all engineers and
> (especially) for all managers.

Obviously an engineer's view of poor management.

Ian

"Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> wrote in message
news:4028fe8d_1@mk-nntp-1.news.uk.worldonline.com...
> Al Borowski wrote:
>
> > Ian Bell wrote:
> >> David Brown wrote:
> >>
> >>
> >>>If there are exceptions, then it is not a rule.  The common opinion
among
> >>>PHBs is that C is "easier" than assembly, and therefore every embedded
> >>>project should be written in C and not assembly.
> >>
> >>
> >> Forgive my ignorance but what is a PHB??
> >
> > Pointy-Haired-Boss - The moronic manager from dilbert.
http://dilbert.com
> >
> > Al
>
> AH, now I understood.  Never did get into Dilbert.
>
> Ian

"The Dilbert Principle" should be required reading for all engineers and
(especially) for all managers.

Rene Tschaggelar wrote:
> Frank Bemelman wrote:
> > "Rene Tschaggelar" <none@none.net> schreef in bericht
> >
> >> Acknowledging your defense of the old stuff, the short names
> >> become a nightmare when the names resolve to almost identity. Eg.
> >>
> >> TempCtrlV1.asm
> >> TempCtrlMath.asm
> >> TempCtrlComm.asm
> >> TempCtrlLoop.asm
> >> TempCtrlV2.asm
> >>
> >> Why should I not have longer names, just because some lazy guys
> >> have other stuff to do ? I myself write Win32 applications.
> >> They are not such a big fuss. It is quite easy actually.
> >
> > I have a file here, ANALFUN.C, that, yes you guessed it, keeps
> > all the analysis functions ;)
> 
> Thanks for trying Frank,
> you're not dragging me back to stone age.
> I'm happy with Win32.

This started with somebody muttering about 32 bit vs 16 bit MPLAB,
not about Win32 vs Win16.  These are entirely different subjects.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

"Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> schreef in bericht
news:4028fcf7_1@mk-nntp-1.news.uk.worldonline.com...
> Frank Bemelman wrote:
>
> >
> > It's about time to settle once and for all that C is better
> > than assembler. Time has diminished all arguments that favour
> > assembler, in general, and there is no reason to continue to
> > live under a pile of rocks.
>
> I have never really understood why anyone would think one tool is, in
> general, better than another.  Each has its pro and cons and consequently
> applications in which it is 'better' than the other.

There you go. In *general* C is better. In certain and less mainstream
applications, ASM may well be the better choice.

Nothing wrong to say a tool is better, in general. I prefer matches
over flintstones. In general.


-- 
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)

Al Borowski wrote:

> Ian Bell wrote:
>> David Brown wrote:
>> 
>> 
>>>If there are exceptions, then it is not a rule.  The common opinion among
>>>PHBs is that C is "easier" than assembly, and therefore every embedded
>>>project should be written in C and not assembly.
>> 
>> 
>> Forgive my ignorance but what is a PHB??
> 
> Pointy-Haired-Boss - The moronic manager from dilbert. http://dilbert.com
> 
> Al

AH, now I understood.  Never did get into Dilbert.

Ian

Frank Bemelman wrote:

> "Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> schreef in bericht
> news:4028b1f6_1@mk-nntp-1.news.uk.worldonline.com...
>> Dan wrote:
>>
>> > On Mon, 09 Feb 2004 08:41:42 +1000, Al Borowski
>> > <aj.borowski@erasethis.student.qut.edu.au> wrote:
>> >
>> >
>> >>ClrMem: ; writes zeros to memory, 100h to 3ffh
>> >>
>> >>clr R0 ; clear R0
>> >>ldi ZH, 1 ; setup Z to point to the start of memory
>> >>ldi ZL, 0
>> >
>> > Just as a suggestion, there's almost no need to write in assembly
>> > language.  You can accomplish more, and accomplish it more quickly, if
>> > you use a higher level programming language like C or C++.  It's an
>> > excellent skill to know assembly language, it gives to a handle on to
>> > what's really going on.  And it can also be very useful to look at the
>> > assembly code generated by the C compiler in order to aid debugging.
>> > But you'll end up writting better code if you start doing it in C or
>> > C++.
>>
>> Let's not get into the C vs assembler debate but there is no reason why
> you
>> will write *better* code in C, whatever that is.
> 
> It's about time to settle once and for all that C is better
> than assembler. Time has diminished all arguments that favour
> assembler, in general, and there is no reason to continue to
> live under a pile of rocks.

I have never really understood why anyone would think one tool is, in
general, better than another.  Each has its pro and cons and consequently
applications in which it is 'better' than the other.

Ian

Ian Bell wrote:
> David Brown wrote:
> 
> > If there are exceptions, then it is not a rule.  The common opinion
> > among PHBs is that C is "easier" than assembly, and therefore
> > every embedded project should be written in C and not assembly.
> 
> Forgive my ignorance but what is a PHB??

You have been adjudged in the world of comics readers, and
convicted of malfeasance, i.e. failure to read Dilbert.  Sin no
more, lest the Pointy Haired Bosses get you.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

"David Brown" <david@no.westcontrol.spam.com> schreef in bericht
news:c0al8d$gc7$1@news.netpower.no...
>
> "Frank Bemelman" <fbemelx@euronet.invalid.nl> wrote in message
> news:4028cf5e$0$235$a344fe98@news.wanadoo.nl...
> > "David Brown" <david@no.westcontrol.spam.com> schreef in bericht
> > news:c0afcv$dm5$1@news.netpower.no...
> >
> > > This summary covers many such threads, but not this one:
> >
> > Another one came to mind. If assembly takes more time, and
> > time is not an infinite resource, the final application is
> > bound to have either less performance or less functionality
> > and presumably lack both.
> >
>
> "Assuming that C is better than assembly in all ways, it is better to
write
> the application in C than assembly.  QED."
>
> You are determined to re-state your mantra no matter what, aren't you?  If
> you don't like assembly, then that's fine - don't use it.  But leave the
> rest of us to choose the right tool for the right job.

I'm in favour of the right tool for the right job. Just wondered
about possible consequences. That's why I started with *If*.

> Short development time is *one* aspect of picking the right tools, but it
is
> not the only one.  It might take longer to write a program if you want to
> check all the generated assembly rather than simply assuming your C
compiler
> is bug-free, has a perfect optimiser, and is able to read your mind, but
the
> resulting program will be more efficient (and perhaps have fewer bugs,
since
> you have checked it more carefully).  That will often equate to smaller
and
> cheaper hardware and lower clock speeds.
>
> To step up a level for comparison, why do people still use C when
> programming on PCs?  After all, using a language like Python would lead to
> far shorter development times and avoid a great many common bugs and
> security holes that often appear in big C programs (since the language
helps
> avoid buffer overflows and memory allocation issues).  If you want to get
> the very best out of a python program, however, it can be a great help to
> understand the underlying virtual machine and function implementations,
> which are written in C, and it may make sense to write C-level extensions
to
> your python code.

Why? More mature tool chains, and more experience with it. Which is not
a reason for not looking around. Like there are other convenient tools
too, such as Delphi or VB. It depends on what you do and where you are.

My mantra is not to ban assembly, my latest project had ~15% assembly
for good reasons. My previous project less than 0.1%. That project
was a total makeover of an inherited 100% assembly project. Running
on the same hardware. Proves nothing, but it does make clear that
assembly certainly isn't the holy grail that we are supposed to believe
it is.

For all practical - rule of thumb - purposes, assembly is dead. I have
not seen one single line of assembly in Dr. Dobbs for the last ten years.
It's reserved for small arenas such as 'close to the metal' drivers and
what have you.

You might say I get upset, when I hear die-hard assembly coders ;)


-- 
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)

"Frank Bemelman" <fbemelx@euronet.invalid.nl> wrote in message
news:4028cf5e$0$235$a344fe98@news.wanadoo.nl...
> "David Brown" <david@no.westcontrol.spam.com> schreef in bericht
> news:c0afcv$dm5$1@news.netpower.no...
>
> > This summary covers many such threads, but not this one:
>
> Another one came to mind. If assembly takes more time, and
> time is not an infinite resource, the final application is
> bound to have either less performance or less functionality
> and presumably lack both.
>

"Assuming that C is better than assembly in all ways, it is better to write
the application in C than assembly.  QED."

You are determined to re-state your mantra no matter what, aren't you?  If
you don't like assembly, then that's fine - don't use it.  But leave the
rest of us to choose the right tool for the right job.

Short development time is *one* aspect of picking the right tools, but it is
not the only one.  It might take longer to write a program if you want to
check all the generated assembly rather than simply assuming your C compiler
is bug-free, has a perfect optimiser, and is able to read your mind, but the
resulting program will be more efficient (and perhaps have fewer bugs, since
you have checked it more carefully).  That will often equate to smaller and
cheaper hardware and lower clock speeds.

To step up a level for comparison, why do people still use C when
programming on PCs?  After all, using a language like Python would lead to
far shorter development times and avoid a great many common bugs and
security holes that often appear in big C programs (since the language helps
avoid buffer overflows and memory allocation issues).  If you want to get
the very best out of a python program, however, it can be a great help to
understand the underlying virtual machine and function implementations,
which are written in C, and it may make sense to write C-level extensions to
your python code.


> Yet another reason to sweep assembly where it belongs. And
> that's a rather small arena, getting smaller by the day.
>
>
> --
> Thanks, Frank.
> (remove 'x' and 'invalid' when replying by email)
>
>
>