Re: [dsdp-dd-dev] Disassembly View Requirement

[Duane Ellis <duane_ellis@xxxxxxxxxxxx>]

My $0.02...

This gets complicated very fast.

==================================================

A system may have multiple targets ... some 
think of DUAL CORE as two of the same CPU execution 
units. That's not always the case. An example is an
ARM + some onchip DSP - TI makes such a chip.

        Search google for:  "TMS320DM64x DSPs"

TI is not alone, www.arm.com has TEAK and OAK dsps.

==================================================

I would view this feature like this:

The default memory view is a byte dump.

The memory view window probably needs a means to 
respond to something like a "right-click - force 
some action at this byte location" command.

The "force" option might be "format specific"

For example:
        Force - this byte as the 1st byte of an opcode
        Toggle: Big-v-Little Endian
        Force - ARM not THUMB opcodes starting here.

==================================================

Above, I used the example of different disassemblers
such as a DSP vrs ARM opcodes.. That is not always
the case... these are other examples:

Think of this as a "View as..." selection from the
memory view window.

A hiearchy with [+] to-expand-buttons

For example - 
        a JAVA jar file is really a ZIP file
        a MP3 file has frame headers + data
        Some MP3 headers are ID3 tags...

Another example of this is REGISTERs on a chip.
        For example ATMEL AT91RM9200 - has many IO
        devices on chip, serial ports, IRQ controller
        USB, GPIO pins, and the like.

        Being able to click & see configuration 
        registers explained in english is nice...

Other non-chip things could be plugged into the view.
There are some very generic ones such as:

        In-memory view of an ethernet packet 
        a 'fly-by-wire' protocol for airplanes
        GSM frame packet {if there is such a thing}
        a BMP or JPEG file viewer.
        An image dump/view from a camera chip.

One should also be able to specify that a specific
byte is the 1st byte of a "C/C++" structure used
in their program.

There are also "vendor specific" formats.

   In our case, we create electronic books. 
   The data we point at might be an ebook 
   specific compression format... with a 
   header and data... etc.

I'm sure the guys at Symbian & Nokia have their
formats also.

==================================================

While the above may be nice... a primary rule is
the "memory-view-plugin" needs to be robust.

Often times the data you point at is utterly wrong.
Think of choosing "View as Windows BMP" when the
data is actually random gibberish.

Also a "Dereference this as a pointer to..." 

Remember: This is a debugger. Perhaps the bug is
the data in the BMP header your program is trying
to display - let us not crash the debugger.

Duane Ellis
Principal Engineer
Franklin Electronic Publishers
One Franklin Plaza
Burlington NJ 08016
email: duane_ellis@xxxxxxxxxxxx
voice: 1-609-386-2500 x4918
skype: duane_ellis