I compiled your code exactly as you said both in AMD64 and in an Intel machine. I tried diff between both .hex files and they are identical. The .lst files differed only in their time-stamps. The .cod files differed as well, but I could not really tell what because those are binaries -- anyway, with diff -a (to treat binary as text files) it seemed to do with the time-stamp as well.
About gpsim, you were right, latest versions do support 18f1220 (I guess they just didn't update the text file PROCESSORS...).
I reproduced your steps using gpsim just like you said (with both Intel and AMD64 .cod files, just in case) and the result was identical.
Now I will go try the exact code I used in the device to see what gpsim shows...
> You said you tested with gpsim and I attempted to try as well but
> gpsim (as of 0.22.0) seems not to support the PIC 18F1220 processor.
> Apparently the only 16bit PIC it supports is 18Cxx2 but even this
> seems to be not fully supported yet (accordingly to gpsim/PROCESSORS
> in their sources).
I use gpsim 0.21.12-pre (it may be an svn version, no official release);
reveals that the pic18f1220 is/was supported. [Update: Looked up and
tried with the gpsim-0.22.0 release; also supports the pic18f1220, also
yields the same good results on my IA32 box.]
Then I feed my code (below again in full) using
sdcc -mpic16 -p18f1220 -Wl,-m deref.c
gpsim -i -s deref.cod
(My actual sdcc invocation has more -I and -L paths specified, but these
should not matter.)
unsigned char glo;
unsigned char c = 0x34;
unsigned char *p;
p = &c;
*p = 0x12;
glo = 0;
if (*p == 0x12)
glo = 1;
if (*p == 0x34)
glo = 2;
if (c == 0x12)
glo |= 4;
if (c == 0x34)
glo |= 8;
Then I use the step command (step [Enter], [Enter], [Enter], ...) to
obtain verbose output from the simulator, ignoring all warnings until it
spins at the `bra $-0x0' instruction after having left main(). Scrolling
back reveals that glo has been assigned 1 first and then its second bit
has been set, indicating that both writing c via *p and reading back
from both c and *p work nicely.
Another way to obtain this result is to use the dump command after the
simulator spins in the endless loop and look at memory locations
0x80..0x81 (according to my .map file, c goes to 0x80 and glo goes to
0x81). I find 0x80 holding 0x12 and 0x81 storing the desired value of
> Now I wonder if the problem could be more specific to certain types of
> 16bit MCUs.
Feel free to send me your .asm/.cod/.hex/.map/.lst files as generated by
SDCC from the code above (or your failing test code)---maybe SDCC emits
wrong code on AMD64?!? (Send these file to my personal mail account
rather than the list, though.)
> Which PIC did you use in your simulation?
pic18f1220 as described above.
Hope that helps,
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
Sdcc-user mailing list