Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#12 missing push/pop pair

closed-fixed
nobody
5
2000-09-30
2000-06-25
Anonymous
No

Hi Sandeep,

at first I'd like to thank you and the other involved in the sdcc project for
doing such great work. I have been searching many times for an 8051 compiler
which is comparably fast as commercial products but being open-source.

Developing a medium size project (Siemens 80c517A based "auto-pilot" for an
model thermal glider airplane) I was forced to program an Intel-Hex-File
reading boot loader (utilizing one of the serial interfaces) which may be used
to download the functional code into flash program memory.

As a first step I tried to design an Intel-Hex-reading function. Because this
file format is very simple I didn't expect much difficulties...
I was surprised that the checksum accumulation didn't work at all. It seemed
as if there were "swallowed" bytes. To debug this code I used already made
serial I/O-routines which enabled me to use one RS232 to perform debug output
while the other is bound to the Intel-Hex supplying terminal.
I discovered the astonishing fact that the code worked properly if the
debugging output was made (line 76) and didn't work if the "production
version" of the code was compiled (without the debugging output).
By comparing the list files of o.k. and defective code I found that the call
of the serial output function not only changed the nearby code but the
following, too. This may be the reason why the checksum calculation is
corrupted if no serial output is made.
I enclosed the important part of the function:

/* get higher byte of first address */
databyte = monitor_readbyte();
checksum += databyte;
serial0_put_hex_byte(checksum); /*!!! may not be commented out!!!*/
address = (unsigned int)databyte << 8;

/* get lower byte of first address */
databyte = monitor_readbyte();
checksum += databyte;
address += databyte;

If the marked line (76) /* !!! ... !!!*/ is included, the following code
fragment is generated:

523 ; monitor.c 75
0074 EB 524 mov a,r3
0075 2A 525 add a,r2
0076 FC 526 mov r4,a
527 ; monitor.c 76
0077 C0 02 528 push ar2
0079 C0 03 529 push ar3
007B C0 04 530 push ar4
007D 8C 82 531 mov dpl,r4
007F 12s00r00 532 lcall _serial0_put_hex_byte
0082 D0 04 533 pop ar4
0084 D0 03 534 pop ar3
0086 D0 02 535 pop ar2
536 ; monitor.c 80
0088 C0 02 537 push ar2
008A C0 04 538 push ar4
008C 12s00r07 539 lcall _monitor_readbyte
008F AB 82 540 mov r3,dpl
0091 D0 04 541 pop ar4
0093 D0 02 542 pop ar2

If the line (76) is commented out, it looks like:

523 ; monitor.c 75
0074 EB 524 mov a,r3
0075 2A 525 add a,r2
0076 FC 526 mov r4,a
527 ; monitor.c 80
0077 C0 02 528 push ar2
0079 12s00r07 529 lcall _monitor_readbyte
007C AB 82 530 mov r3,dpl
007E D0 02 531 pop ar2

You may see, the code originating from line 80 lacks a push/pop pair which
saves and restores ar4 onto/from the stack. The function monitor_readbyte
(which is contained in the same module) uses and destroys ar4.

I'm using sdcc 2.2.0 (Linux) which I got from the CVS tree today (July 25th).
The compiler was invoked by
sdcc -c monitor.c -I /root/micro/sdcc/device/include/ --code-loc 0x8000
--xram-l oc 0x0000 --data-loc 0x30 --stack-after-data
-L//D/usr/local/share/lib/small -I//D/usr/local/share/include/
without any additional #pragmas.

I'll try to work_around the problem but would be glad if you could find the
problem.

Like many others I thank you very much for your great work and hope it will
continue.

Greetings from Germany

Kai

Discussion

  • Sandeep Dutta
    Sandeep Dutta
    2000-09-30

    Fixed in latest source tree

     
  • Sandeep Dutta
    Sandeep Dutta
    2000-09-30

    • status: open --> closed-fixed