----- Original Message -----
From: "Anders Lindgren"
To: m...
Sent: Thursday, November 15, 2007 9:35:06 AM (GMT-0700) America/Denver
Subject: Re: [msp430] Re: Complete Assembler Listing from IAR C project
Aaron Greer wrote:
>
> ----- Original Message -----
> From: "Anders Lindgren" < A...@iar.se
> >
> To: m...
> Sent: Thursday, November 15, 2007 12:47:31 AM (GMT-0700) America/Denver
> Subject: Re: [msp430] Re: Complete Assembler Listing from IAR C project
>
> Anders:
> > The compiler and assembler can generate list files for each source file
> > they compile. We don't have a feature to generate a list file of the
> > result after linking.
>
> Aaron Greer:
> > Wow, that surprises me. Doesn't that seem like a useful feature? As it
> > is now, I guess the only way to get a glimpse of the linked assembly
> > code is in the disassembly window of the debugger. How hard would it be
> > to add a context menu item that will copy the entire disassembly window
> > contents to the clipboard (instead of just the visible portion)?
>
> Hi Aaron!
>
> Yes, I guess that it would be a nice feature, but it's really not as
> easy as it sounds. To generate one big list file, we would either have
> to modify the object code format to include the assembler source, or
> implement a disassembler into the otherwise generic linker.
>
> On the other hand, the linker can produce a so-called "map-file". It
> doesn't include the assembler source, but it list exactly which parts
> that was included from each object file, and where they are placed. For
> most parts, this is more usefule than pages and pages of assembly.
>
> -- Anders Lindgren, IAR Systems
> --
> Disclaimer: Opinions expressed in this posting are strictly my own and
> not necessarily those of my employer.
>
> Anders,
> I can see where you are coming from, and I appreciate the difficulty of
> the task. My reason for wanting the feature is largely due to my present
> circumstances, not necessarily an intrinsic need. I am the junior
> engineer here and I was asked to provide an assembly listing of the
> complete application after linking. I've found the linker map file and
> module listing files quite handy in fact. But, those things don't show
> the initializing code or other routines provided by the system such as
> "epilogue". The only place I've found the whole picture is in the debug
> disassembly window. I do have one question for you. The disassembly
> window shows labels, and C code overlaying the assembly code. If this
> type of information can be generated via the debugger, why can't you
> simply take that (which has already been implemented) and extend it to
> export the complete disassembly listing just as it shows in the
> disassembly window? You can already do that by copying one window worth
> at a time, simply extend that to copy the whole window.
> thanks for your reply,
> Aaron

Aaron,
I've just spoken to one of the debugger guys here, he said that this
could be done using C-Spy plugins since the SDK interface supports
accessing the disassembly output.

I'll try to pitch the idea in the right direction, but I can't promise
anything.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

Thanks Anders, that sounds great!

Aaron Start a New Thread

Aaron Greer wrote:
>
> ----- Original Message -----
> From: "Anders Lindgren" > >
> To: m...
> Sent: Thursday, November 15, 2007 12:47:31 AM (GMT-0700) America/Denver
> Subject: Re: [msp430] Re: Complete Assembler Listing from IAR C project
>
> Anders:
> > The compiler and assembler can generate list files for each source file
> > they compile. We don't have a feature to generate a list file of the
> > result after linking.
>
> Aaron Greer:
> > Wow, that surprises me. Doesn't that seem like a useful feature? As it
> > is now, I guess the only way to get a glimpse of the linked assembly
> > code is in the disassembly window of the debugger. How hard would it be
> > to add a context menu item that will copy the entire disassembly window
> > contents to the clipboard (instead of just the visible portion)?
>
> Hi Aaron!
>
> Yes, I guess that it would be a nice feature, but it's really not as
> easy as it sounds. To generate one big list file, we would either have
> to modify the object code format to include the assembler source, or
> implement a disassembler into the otherwise generic linker.
>
> On the other hand, the linker can produce a so-called "map-file". It
> doesn't include the assembler source, but it list exactly which parts
> that was included from each object file, and where they are placed. For
> most parts, this is more usefule than pages and pages of assembly.
>
> -- Anders Lindgren, IAR Systems
> --
> Disclaimer: Opinions expressed in this posting are strictly my own and
> not necessarily those of my employer.
>
> Anders,
> I can see where you are coming from, and I appreciate the difficulty of
> the task. My reason for wanting the feature is largely due to my present
> circumstances, not necessarily an intrinsic need. I am the junior
> engineer here and I was asked to provide an assembly listing of the
> complete application after linking. I've found the linker map file and
> module listing files quite handy in fact. But, those things don't show
> the initializing code or other routines provided by the system such as
> "epilogue". The only place I've found the whole picture is in the debug
> disassembly window. I do have one question for you. The disassembly
> window shows labels, and C code overlaying the assembly code. If this
> type of information can be generated via the debugger, why can't you
> simply take that (which has already been implemented) and extend it to
> export the complete disassembly listing just as it shows in the
> disassembly window? You can already do that by copying one window worth
> at a time, simply extend that to copy the whole window.
> thanks for your reply,
> Aaron

Aaron,
I've just spoken to one of the debugger guys here, he said that this
could be done using C-Spy plugins since the SDK interface supports
accessing the disassembly output.

I'll try to pitch the idea in the right direction, but I can't promise
anything.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer. Start a New Thread

--- Aaron Greer wrote:
> ----- Original Message -----
> From: "old_cow_yellow"
> To: m...
> Sent: Tuesday, November 13, 2007 11:49:04 AM
> (GMT-0700) America/Denver
> Subject: [msp430] Re: Complete Assembler Listing
> from IAR C project
>
> Note that:
> (1) If more than one symbol has the same value, the
> Disassembler may
> pick the wrong symbol to represent that value.
> (2) If data (constants etc.) are encountered, the
> Disassembler will
> interpret those data as code, and it will not make
> any sense.
> (3) The Disassembler may occasionally mis-align the
> boundary of a
> multi-word instruction and it will not make any
> sense.
>
Now you know some of my frustrations with IAR. They
will do only what it is |easy" for them, completely
ignoring the needs of their users. I have compiled a
list of 114 "bugs" like this and I keep it posted on
the wall right above my screen as a remainder how not
to make a product :(

Sorry Anders but this is the truth.
I have switched to FORTH an I am content now :)

Without Wax.
BB
____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs Start a New Thread

bumerang boom wrote:
> Now you know some of my frustrations with IAR. They
> will do only what it is |easy" for them, completely
> ignoring the needs of their users.

Ouch, that hurt! I'm sorry you feel that way... However, I don't see
myself as a person (or IAR a company) as someone that preferes to take
the easy way out. Hey, I just spent months implementing support for the
new data models of MSP430X, easy? No!
> I have compiled a
> list of 114 "bugs" like this and I keep it posted on
> the wall right above my screen as a remainder how not
> to make a product :(

If you like you can sent the list to me -- getting input from people
that like your program can be sweet, but getting it from someone that
doesn't is often more constructive.
> Sorry Anders but this is the truth.

If that really is the truth, then I'm sorry too...

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer. Start a New Thread

> Note that:
> (1) If more than one symbol has the same value, the
> Disassembler may
> pick the wrong symbol to represent that value.
> (2) If data (constants etc.) are encountered, the
> Disassembler will
> interpret those data as code, and it will not make
> any sense.
> (3) The Disassembler may occasionally mis-align the
> boundary of a
> multi-word instruction and it will not make any
> sense.

Now, that's not fair.
Aaron's context for this was NOT in the context you put it !
Besides, AFAIK _any_ disassembler will do this...
I've certainly never seen a disassembler that picks the runtime constants... and how could it
anyway ? (I know, the symbol table could help with that, but we're talking DISassembler)

Best Regards,
Kris

-----Original Message-----
From: m... [mailto:m...] On Behalf Of bumerang boom
Sent: Friday, 16 November 2007 6:43 PM
To: m...
Subject: Re: [msp430] Re: Complete Assembler Listing from IAR C project Start a New Thread

At 02:37 AM 11/16/2007, microbit_virgin wrote:

>Now, that's not fair.
>Aaron's context for this was NOT in the context you put it !
>Besides, AFAIK _any_ disassembler will do this...
>I've certainly never seen a disassembler that picks the runtime
>constants... and how could it
>anyway ? (I know, the symbol table could help with that, but we're
>talking DISassembler)

It IS possible. For M8C, precisely for this problem (of assembler
programmers wanting to put data in the middle of code stream), we
introduce pseudo-ops

.LITERAL
...
.LITERAL_END

that the information is carried to the listing file generator that
everything works out.

It's amazing what it's possible given enough push :-)

// richard (This email is for mailing lists. To reach me directly,
please use richard at imagecraft.com) Start a New Thread

Richard,

> >Now, that's not fair.
> >Aaron's context for this was NOT in the context you put it !
> >Besides, AFAIK _any_ disassembler will do this...
> >I've certainly never seen a disassembler that picks the runtime
> >constants... and how could it
> >anyway ? (I know, the symbol table could help with that, but we're
> >talking DISassembler)
>
> It IS possible. For M8C, precisely for this problem (of assembler
> programmers wanting to put data in the middle of code stream), we
> introduce pseudo-ops
>
> .LITERAL
> ...
> .LITERAL_END
>
> that the information is carried to the listing file generator that
> everything works out.
>
> It's amazing what it's possible given enough push :-)

CrossWorks trumps that--you don't even need to put that type of directive
into your code, CrossWorks' disassembler (aka object file lister) knows how
each byte of an application was generated and does the right thing. ;-)
Has done since V1.0.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors Start a New Thread

Ok, I did stipulate dis_assembler, I meant in its literal sense.
Especially with literal pools, how does a disassembler know they're literals ?
It can't.

IOW what I meant was this :
Disassemble some machine code - read from a flashed part. The literal pool (eg.) will be
disassembled as instructions.
There's no way the dis can tell them apart.

Best Regards,
Kris

-----Original Message-----
From: m... [mailto:m...] On Behalf Of Richard
Sent: Friday, 16 November 2007 10:42 PM
To: m...; m...
Subject: RE: [msp430] Re: Complete Assembler Listing from IAR C project

At 02:37 AM 11/16/2007, microbit_virgin wrote:

>Now, that's not fair.
>Aaron's context for this was NOT in the context you put it !
>Besides, AFAIK _any_ disassembler will do this...
>I've certainly never seen a disassembler that picks the runtime
>constants... and how could it
>anyway ? (I know, the symbol table could help with that, but we're
>talking DISassembler)

It IS possible. For M8C, precisely for this problem (of assembler
programmers wanting to put data in the middle of code stream), we
introduce pseudo-ops

.LITERAL
...
.LITERAL_END

that the information is carried to the listing file generator that
everything works out.

It's amazing what it's possible given enough push :-)

// richard (This email is for mailing lists. To reach me directly,
please use richard at imagecraft.com) Start a New Thread

Well, I may have jumped into the middle of the thread and didn't
realize the premise has been changed :-) I thought the original
request was "Complete Assembler Listing from (IAR) C project" as
reflected by the title. Point is, ImageCraft and Rowley can do it, in
the context of a C project. (Paul, good job. I didn't want to change
the existing relocation architecture too much more. I am glad someone
is even more ambitious than I am :-) ).

In the general disassembler case, what you describe will only be
possible if the disassembler actually tries to "understand" the code,
and even then, obviously one can fake it. But really that becomes an
academic exercise, so I will concede that under your premise, you win :-)

At 04:24 AM 11/16/2007, microbit_virgin wrote:
>Ok, I did stipulate dis_assembler, I meant in its literal sense.
>Especially with literal pools, how does a disassembler know they're literals ?
>It can't.
>
>IOW what I meant was this :
>Disassemble some machine code - read from a flashed part. The
>literal pool (eg.) will be
>disassembled as instructions.
>There's no way the dis can tell them apart.
>
>Best Regards,
>Kris
>
>-----Original Message-----
>From: m... [mailto:m...] On
>Behalf Of Richard
>Sent: Friday, 16 November 2007 10:42 PM
>To: m...; m...
>Subject: RE: [msp430] Re: Complete Assembler Listing from IAR C project
>
>At 02:37 AM 11/16/2007, microbit_virgin wrote:
>
> >Now, that's not fair.
> >Aaron's context for this was NOT in the context you put it !
> >Besides, AFAIK _any_ disassembler will do this...
> >I've certainly never seen a disassembler that picks the runtime
> >constants... and how could it
> >anyway ? (I know, the symbol table could help with that, but we're
> >talking DISassembler)
>
>It IS possible. For M8C, precisely for this problem (of assembler
>programmers wanting to put data in the middle of code stream), we
>introduce pseudo-ops
>
>.LITERAL
>...
>.LITERAL_END
>
>that the information is carried to the listing file generator that
>everything works out.
>
>It's amazing what it's possible given enough push :-)
>
>// richard (This email is for mailing lists. To reach me directly,
>please use richard at imagecraft.com)
> Start a New Thread