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)
I found a bug with v6.20 which messed up a function with a long parameter, but v6.22 fixed that for me. (the body of my function was actually written as inline assembler). The key section in the Release Notes seems to be: "C51 v6.20 introduced 'Dynamic Register Allocation'. C51 v6.22 corrects several problems that were introduced by this new optimisation technique"
I am concerned about the remark, 'The simulator also shows "extra" hex addresses on the call stack, but is "normal" when the params are ints'. The C51 compiler is not stack based. Only the return address should have shown up on the stack.
I'm new to uV2, but the call stack window shows things like this for the problematic function: 000:\EPSON\EGDBUFFERGET \BLINKY\MAIN\129 001:C:0x0029C3 \BLINKY\MAIN\129 002:C:0x0029C3 \BLINKY\MAIN\129 003:C:0x0029C3 \BLINKY\MAIN\129 004:\BLINKY\MAIN C:0x000000 Another odd thing to note is that I can't use F11 to step into this "bad" function, I must must select Debug->Step via the menu. Kevin
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.