Menu
▾
▴
#1563 code generation bug
1. For sample code, please see the 'sample.c' attachment.
2. Exact command used to run SDCC on the sample code:
Tried both 'sdcc -mmcs51 sample.c' and 'sdcc -mmcs51 --model-medium sample.c'. With the former command, the code works as expected. With the --model-medium option however, the code does not work as expected.
3. SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.9.2 #5492 (Aug 17 2009) (MINGW32)
4. Depending on the options specified, sometimes some code is not executed. Please see the 'sample.c' attachment for more information.
Jelle,
I cannot reproduce this bug. Looking at the generated asm all seems fine.
What mcu are you using?
Does it have internal XDATA?
Is it disabled by default?
Is _XPAGE correctly defined?
Maarten
Maarten,
I'm using the TUSB3210 which has an 8052 MCU. It does have internal XDATA, which isn't disabled by default. Also, I have not defined _XPAGE.
If you want to have a look at the data manual of the device, see: http://www.tusb3210.com/Download/tusb3210.pdf
HTH,
Jelle
I've looked briefly into the datasheet and to my surprise there was no sfr map. They claim it is fully 8052 compatible, though I think that is unlikely with internal xdata. I doubt if setting P2 to 0xFD, 0xFE or 0xFF before a MOVX @Ri instruction will target the internal xdata, but who knows. My guess is that it is only possible to access it with MOVX @DPTR and thus --model-medium does not work. Moreover this would also mean that xdata initialization (crtxinit.asm) will not work and must be adapted. Finally, did you specify --xram-loc while linking your app. because the internal xdata is not at 0x0000?
Maarten
Forgot to specify --xram-loc. But even if I am going to specify it correctly, it might not work because --model-medium (and --medium-large?) are not supported by SDCC on my device (at least at this moment)?
Typo, that --medium-large in my last comment should be --model-large.
Well, I don't know for sure, but I suspect initialization of global variables in pdata and xdata will not work as it uses MOVX @Ri. Medium model puts all variables in pdata by default and Large model in xdata.
If pdata access indeed does not work, you could adapt crtxinit.asm to at least make xdata initialization work. Otherwise you could use --no-xinit to overcome this at the price of a probably larger code size.
Please report back if you found out if pdata is supported or not on this device.
Please close the report too at the same time.
I've ran a test to create memory maps (see the map.c attachment).
The thing is, even with --model-medium, 0xfd80 was writable, but only up till 0xfeff (instead of the usual 0xff7f).
I'll attach the test (C version + generated assembly) that I used to determine which memory was writable.
Also, I don't think I should modify crtxinit.asm before knowing more about whether we can get MOVX @Ri working (if that's really the culprit).
If the issue is really that MOVX @Ri doesn't work, then I guess the real issue is lack of documentation from Texas Instruments? In that case, the bug report probably should be closed and people using this device should use --no-xinit when using --model-medium.
Another test revealed that, when using --model-medium, a 'char arr[128]' works fine (even with MOVX @Ri, it seems, by looking at the generated assembly code). But an array larger than that is unreliable/unsupported.
Jelle,
You cannot test xdata like this if you let the compiler put variables in the same xdata memory. On top of that you write to P2 which might disturb the selected pdata page (if that works).
Only the small model test is correct and it shows that you can access all 512 bytes with MOVX @DPTR.
To test MOVX @Ri you stay in the small model, erase xdata and then perform the test with a pdata pointer (0..255). Do not touch P2.
Then test again but with P2=0x00, 0xFD, 0xFE and 0xFF resp. to see if the contents of P2 selects the page. My guess is that it doesn't and you can only use medium model with real external ram and only access internal xdata through the DPTR.
When xram starts at 0xFD80 the pdata area will start there and it cannot grow beyond 0xFDFF and thus the array (in pdata) cannot grow beyond 128 bytes.
Good point. I had a hunch something was going on because of the odd memory map result for --model-medium.
Perhaps I can hook up an LCD (for which I'd only need to write to P0) to display test info.
If we can only access internal xdata using DPTR, is it still possible to get --model-medium to work (albeit with some changes to SDCC, perhaps)? Not that I really need --model-medium, but still.
No of course not. The medium memory model is based on MOVX @Ri access. It tries to benefit from two pointers (R0, R1) instead of only one (DPTR) for large model and smaller calculations on the pointers themselves. And it provides access to more bytes in default memory (upto 256 bytes pdata) than small model (upto 120 bytes data) at the cost of indirect access only.
I close the bug report now, but if you ever find out if MOVX @Ri works on internal xram for this device you can still add that information for future reference.