• State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 22 subscribers
  • Views 1294 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

long params

Kevin Radke

I'm having some bizarre behavior with functions that take multiple long values as parameters. If I change them to ints, all is fine, but if they are longs the target locks up on the function call. The simulator also shows "extra" hex addresses on the call stack, but is "normal" when the params are ints.

I simply have a main() routine that calls the following function:

unsigned char *GetBuffer(long, long, long, long);

I.E. b=GetBuffer(0, 320, 240, 1);

Am I missing something obvious?
The target is a 80C390, but I'm not
running in contiguous mode (yet), just in the large memory model.

I just updated to v6.22. (But I had not tried this with v6.21)

Parents
  • 0

    C functions normaly pass parameters in registers. If no registers available parameters passed in fixed memory locations.

    When entering the function some internal subroutines are called to save the parameters into local variables.
    So you see the return adress from these subroutines.

    Is this what you mean?

    Chris

Reply
  • 0

    C functions normaly pass parameters in registers. If no registers available parameters passed in fixed memory locations.

    When entering the function some internal subroutines are called to save the parameters into local variables.
    So you see the return adress from these subroutines.

    Is this what you mean?

    Chris

Children
  • 0 in reply to Christian Bienert

    "C functions normaly pass parameters in registers."

    Just to be clear, this is specific to C51 - to overcome the limitations of the 8051's hardware stack.
    In general, on machines where stack space is not a problem, parameters are usually passed on the stack.

    "When entering the function some internal subroutines are called to save the parameters into local variables."
    Normally, the caller would write the parameters direct to the fixed memory locations.

  • 0 in reply to Andy Neil

    Here is some more data.

    The function I am calling that works:

    long egdDraw(unsigned char xdata *, int, int);

From the .lst file:

_egdDraw . . . . . . . . . . . . . . .  PUBLIC   CODE   PROC     0000H  -----
  buffer . . . . . . . . . . . . . . .  AUTO     XDATA  PTR      0000H  2
  width. . . . . . . . . . . . . . . .  AUTO     XDATA  INT      0002H  2
  height . . . . . . . . . . . . . . .  AUTO     XDATA  INT      0004H  2
  lsb. . . . . . . . . . . . . . . . .  AUTO     IDATA  U_CHAR   0000H  1
  msb. . . . . . . . . . . . . . . . .  AUTO     IDATA  U_CHAR   0001H  1


The function I am calling that does not work:

long egdDraw(unsigned char xdata *, long, int);


_egdDraw . . . . . . . . . . . . . . .  PUBLIC   CODE   PROC     0000H  -----
  buffer . . . . . . . . . . . . . . .  AUTO     DATA   PTR      0004H  2
  width. . . . . . . . . . . . . . . .  AUTO     XDATA  LONG     0002H  4
  height . . . . . . . . . . . . . . .  AUTO     XDATA  INT      0006H  2
  lsb. . . . . . . . . . . . . . . . .  AUTO     IDATA  U_CHAR   0000H  1
  msb. . . . . . . . . . . . . . . . .  AUTO     IDATA  U_CHAR   0001H  1
    I find it odd it thinks buffer is a DATA ptr here, even though I forced it to be an XDATA ptr.

  • 0 in reply to Kevin Radke

    I am not quite sure what is going on here - may be I misunderstand the question. XDATA/DATA is indicating where the pointer is stored not the type of memory to which it is pointing. Note that in each case the pointer has a size of two bytes - that is consistent with a pointer into XDATA.

    Why should the location of the pointer change? My best guess is that it has something to do with your memory model.