Debugging assembly

> Ditch assembly, get yourself a good C compiler.

Bad advice, that's just assembly with a different set of mnemonics ;-)

Leif Holmgren wrote:

>> Ditch assembly, get yourself a good C compiler.
> 
> Bad advice, that's just assembly with a different set of mnemonics ;-)

And a whole extra bunch or errors to make.

Ian

On Fri, 25 Nov 2005 09:53:14 +0800, Dan N <dan@localhost.localdomain>
wrote:

>On Thu, 24 Nov 2005 06:27:37 -0800, rasega wrote:
>
>
>> Please, what software do U suggest me to simplify this job ??
>
>Ditch assembly, get yourself a good C compiler.

While assembly might not be a cost effective tool for implementing
large (more than a few kilobytes) systems, understanding of
assembly/disassembly at least at a rudimentary level is essential for
working with embedded systems.

Paul
  

Paul Keinanen wrote:

> While assembly might not be a cost effective tool for implementing
> large (more than a few kilobytes) systems, understanding of
> assembly/disassembly at least at a rudimentary level is essential for
> working with embedded systems.

No, I've worked with embedded systems for 25 years now, and whereas I 
had to learn the assembler in the earlier days, everything is in C now. 
It's still not totally portable, because of the closeness to the 
hardware and its vagaries, but I'm supporting four processors at the 
moment, and most of the time I couldn't care which is which.

You only really need assembler if you've underestimated the processor 
capacity, or you have to support someone else's system, or you're 
writing the compiler.

Paul Burke

"Paul Burke" <paul@scazon.com> wrote in message
news:3uvss3F13gnenU1@individual.net...
> You only really need assembler if you've underestimated the processor
> capacity, or you have to support someone else's system, or you're
> writing the compiler.

Or if you want to write in C but want to get the most out of
size/performance. In such cases I frequently check the generated assembly
from the compiler.

Meindert

Thanks All,
I've RTFM and solved many problems (one of the problems was that I
didn't have the manual !!)...now searching for the complete list of the
assembler error codes ...

On Mon, 28 Nov 2005 08:19:06 +0000 in comp.arch.embedded, Paul Burke
<paul@scazon.com> wrote:

[...]
>No, I've worked with embedded systems for 25 years now, and whereas I 
>had to learn the assembler in the earlier days, everything is in C now. 
>It's still not totally portable, because of the closeness to the 
>hardware and its vagaries, but I'm supporting four processors at the 
>moment, and most of the time I couldn't care which is which.
>
>You only really need assembler if you've underestimated the processor 
>capacity, or you have to support someone else's system, or you're 
>writing the compiler.

You've had a very sheltered 25 years.  Most (99% or more) of the code
I write is in C or C++.  But there are things you can do in assembly
that you can't do any other way, or at least, not in C.  For example,
at a PPOE, I needed to write a pseudo-reset routine that would place
all processor registers in the reset state (but leave certain
peripherals untouched) before jumping to the reset vector.

Regards,
   -=Dave
                                        -=Dave

-- 
Change is inevitable, progress is not.

On Mon, 28 Nov 2005 08:19:06 +0000, Paul Burke <paul@scazon.com>
wrote:

>Paul Keinanen wrote:
>
>> While assembly might not be a cost effective tool for implementing
>> large (more than a few kilobytes) systems, understanding of
>> assembly/disassembly at least at a rudimentary level is essential for
>> working with embedded systems.
>
>No, I've worked with embedded systems for 25 years now, and whereas I 
>had to learn the assembler in the earlier days, everything is in C now. 
>It's still not totally portable, because of the closeness to the 
>hardware and its vagaries, but I'm supporting four processors at the 
>moment, and most of the time I couldn't care which is which.
>
>You only really need assembler if you've underestimated the processor 
>capacity, or you have to support someone else's system, or you're 
>writing the compiler.

I noticed in the 1970's that I could not consistently beat the RSX-11
Fortran IV+ compiler by manually translating the modules one by one
into assembly. Of course if I used e.g. global register assignment,
which the compiler did not know anything about, I could write much
better code.

Anyhow, a person working with embedded systems should have a clear
view of what each C/C++ construction will cost in terms of code space
and execution time. Writing an ISR routine entry/exit code as well as
any debugging would still require some understanding of the assembly
language for that platform.

Paul

Ehmmm

Where to find the complete list of "assembly error codes" that the
assembler reports in the .lst file ??
(error 235, error 250, ... )