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
On 1/17/07, Raphael Neider <rneider@...> wrote:
> Hi Rodrigo,
> > 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);
> processor list
> 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.)
> <code name='deref.c'>
> unsigned char glo;
> void main(void)
> 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
> opinions on IT & business topics through brief surveys - and earn cash
> Sdcc-user mailing list
Rodrigo da Silva Guerra
Department of Adaptive Machine Systems
Graduate School of Engineering
Osaka University - Japan