We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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)
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
"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.
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 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.