This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

how to find what to work on when 256 bytes get full

In a compiler I have used earlier it was possible to see directly which databytes were where in the chain so that I did not have to try moving a byte to xdata just to find out that that space was shared by someting else making the move worthless. Is such a table available with Keil? I can make neither head nor tail of the M51 file in this respect.

Erik

  • "I can make neither head nor tail of the M51 file in this respect."

    I'm afraid that's what has the information you require, so you're gonna have to bite the bullet... :-(

    I did write something in Excel once to make some sort of sense (to me) of the data organisation from the M51 file.
    Dunno if it might be of any use to you? (or even if it still works...)

  • pls give me the gist of how to figger it out
    thanx,

    Erik

  • You could consider using some simple filtering tools to extract, for example, the DATA area in the M51 file's SYMBOL TABLE and run that through a sort to get a quick idea of what overlays what and how bit the overlaid areas are.

    gawk -f m51data.awk erik.m51 | sort > m51data.out
    Where m51data.awk is:
    /SYMBOL TABLE OF MODULE:/ {
        do
        {
            if (substr($1, 1, 2) == "D:")
                print
    
        } while (getline)
    }
    And I've uploade a free (GNU/FSF) version of awk for you here:

    http://dhenry.home.sprynet.com/gawk.exe

    Play around with it and see what you think.

    Here's a section of output from one of my M51 files showing overlaid data:
      D:001FH         PUBLIC        AnnuncTmr
      D:0023H         SYMBOL        startClk
      D:0025H         SYMBOL        buf
      D:0025H         SYMBOL        i
      D:0025H         SYMBOL        lcdBuf
      D:0025H         SYMBOL        lcdBuf
      D:0025H         SYMBOL        p
      D:0025H         SYMBOL        pUnadj
      D:0025H         SYMBOL        p_
      D:0025H         SYMBOL        storeCtlNdx
      D:0025H         SYMBOL        t
      D:0025H         SYMBOL        t_
      D:0026H         SYMBOL        p
      D:0026H         SYMBOL        shiftCtr
      D:0027H         SYMBOL        bitCtr
    

  • I minor bit of editing above...

    s/bit/big/
    s/uploade/uploaded/

    Now, with that out of the way...

    Inspecting the sorted output, the addresses having a single data object are where the move to xdata will be the easiest. These are usually associated with data objects having static duration (i.e., globals and those defined static).

  • Thanks Dan, Just back at work after moving, I'll try it when my brain has come back

    Erik

  • OK, and if that simple version does not quite do the trick, we can get a little fancier to get the results you want.

    "If you can spec it, we can tweak it!" (TM) ;-)