Long time MCS51 and more recently STM8 user here.

For STM8 I've noticed that "random" code is generated for the following:

--------------------------------
int sum(int a, int b, unsigned long d)
{
  return a + b / d;
}

int main(void)
{
  return sum(1, 2, 4);
}
--------------------------------

This is using the 3.7.0 #10228 snapshot on Windows 10.0.16299.125.

Compiling ten times as follows, and generating a checksum on the resulting
images:

--------------------------------
sdcc -mstm8 test.c
md5sum test.ihx
--------------------------------

034855cad4e8eb12209ad31c9ccd7f9b *test.ihx 034855cad4e8eb12209ad31c9ccd7f9b
*test.ihx
069a62e6676bd940cb01a36ab3a7f787 *test.ihx
069a62e6676bd940cb01a36ab3a7f787 *test.ihx 034855cad4e8eb12209ad31c9ccd7f9b
*test.ihx 034855cad4e8eb12209ad31c9ccd7f9b *test.ihx
069a62e6676bd940cb01a36ab3a7f787 *test.ihx 034855cad4e8eb12209ad31c9ccd7f9b
*test.ihx 034855cad4e8eb12209ad31c9ccd7f9b *test.ihx
069a62e6676bd940cb01a36ab3a7f787 *test.ihx

The differences occur just after the call to divulong, as can be seen in the
assembly code from runs 2 and 3.

The assembly code for "sum" from run 2:

--------------------------------
;       test.c: 1: int sum(int a, int b, unsigned long d)
;       -----------------------------------------
;        function sum
;       -----------------------------------------
_sum:
        sub     sp, #6
;       test.c: 3: return a + b / d;
        ldw     y, (0x0b, sp)
        clrw    x
        tnzw    y
        jrpl    00103$
        decw    x
00103$:
        ld      a, (0x10, sp)
        push    a
        ld      a, (0x10, sp)
        push    a
        ld      a, (0x10, sp)
        push    a
        ld      a, (0x10, sp)
        push    a
        pushw   y
        pushw   x
        call    __divulong
        addw    sp, #8
        ldw     (0x03, sp), y
        ldw     y, (0x09, sp)
        ldw     (0x01, sp), y
        addw    x, (0x01, sp)
;       test.c: 4: }
        addw    sp, #6
        ret
--------------------------------

The assembly code for "sum" from run 3:

--------------------------------
;       test.c: 1: int sum(int a, int b, unsigned long d)
;       -----------------------------------------
;        function sum
;       -----------------------------------------
_sum:
        sub     sp, #6
;       test.c: 3: return a + b / d;
        ldw     y, (0x0b, sp)
        clrw    x
        tnzw    y
        jrpl    00103$
        decw    x
00103$:
        ld      a, (0x10, sp)
        push    a
        ld      a, (0x10, sp)
        push    a
        ld      a, (0x10, sp)
        push    a
        ld      a, (0x10, sp)
        push    a
        pushw   y
        pushw   x
        call    __divulong
        addw    sp, #8
        ldw     (0x01, sp), y
        ldw     y, (0x09, sp)
        ldw     (0x05, sp), y
        addw    x, (0x05, sp)
;       test.c: 4: }
        addw    sp, #6
        ret
--------------------------------

It looks like this may have been reported before for MCS51 as well:

https://sourceforge.net/p/sdcc/mailman/message/35171634/

But for the example above I don't see the issue for MCS51.

Any thoughts?

 Eric Rullens

 

-----Original Message-----
From: Philipp Klaus Krause [mailto:p...@spth.de] 
Sent: zondag 11 februari 2018 10:09
To: Development chatter about sdcc; Sdcc-User
Subject: [Sdcc-user] SDCC 3.7.0 Release Candidate 1

Dear SDCC developers and users,

Today the first Release Candidate (RC1) for SDCC 3.7.0 has been created.
As always it has been put online in our SourceForge File section.
https://sourceforge.net/projects/sdcc/files/

If you have the time, please verify it and report back with the positive or
negative results.

Since we are having some troubles with some machines in our compile farm,
for 3.7.0 no binaries will be released. The release candiate consists of
source and documentation tarballs only. Also, Maarten, who has been the
release manager for a few years, is currently too busy to manage the 3.7.0
release. We hope to be back to normal for a 3.8.0 release later this year.

There have been a lot of improvements, both features and bug fixes since
SDCC 3.6.0. The full ChangeLog is at
https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-3.7.0-pre1/sdcc/Chan
geLog.

The following is a list of particularly noticeable new features.

* Changed putchar() prototype from void putchar(char) to int
putchar(int) to improve standard-compliance and allow error reporting.
* Various speed improvements in stm8 backend - Dhrystone score more than
doubled, resulting in SDCC achieving the highest Dhrystone scores among
STM8 C implementations.
* Various speed improvements for multiplications resulting in SDCC achieving
the highest Coremark scores among STM8 C implementations.
* Declarations in for loops (ISO C99).
* 64-bit integers (long long) for the mcs51 and ds390 backends (now long
long is fully supported in SDCC except for the pic14 and pic16 backends).
* Full _Bool support for mcs51 and ds390 backend (now _Bool is fully
supported in SDCC regardless of backend).
* Additional wide character library functions: mbstowcs() and wcstombs(),
btowc() and wctob(), wcscmp(), wcslen().
* Changed PRNG for rand() from LCG to xorshift to improve speed and quality.
* Support for Small-C calling convention on the callee side (i.e.
function definitions with Small-C calling convention).
* The obsolete macro SDCC (which used to contain the version number encoded
as an integer) has finally been removed (except for mcs51, where it will
survive a little bit longer for SiLabs IDE compability).
* New devices supported by simulator (TLCS-90, and the 517, F380, XC88X,
DS320 mcs51-variants along with dual-dptr and MDU support).
* Timer, UART (incl. interrupt) and I/O support in STM8 simulator.
* Simulator support for banked memory and bit banding.
* Various simulator improvements: Conditional breakpoints, breakpoints by
function name from SDCC debug output, OMF input, VCD output, simulator
interface for simulated program and new operators in expressions.
* Deprecated --nojtbound and the corresponding pragma.
* Faster register allocator reduces compilation time by about 25% (does not
apply to mcs51, ds390 which use a different register allocator).
* Execution count guessing and use of execution count guesses in stm8
register allocation improve optimization for code speed.
* Changed getchar() prototype from char getchar(void) to int
getchar(void) to improve standard-compliance and allow error reporting.
* Type qualifiers in array parameters (ISO C99).
* static in array parameters (ISO C99).
* Improved support for DWARFv2 debug info in ELF output (stm8, hc08, s08).
* Various improvements in z80/z180/gbz80/tlcs90/r2k/r3ka code generation, in
particular for mixed 16-/32-bit code.
* __z88dk_fastcall function pointer support for --reserve-regs-iy.
* tlcs90 is now a fully supported backend, no longer work in progress.
* --data-seg to specify the segment for non-initialized data in the z80,
z180, gbz80, tlcs90, r2k and r3ka backends.
* New methods to obtain tree-decompositions of control-flow graphs improve
compilation time / code-quality trade-off (when SDCC is built with support
for the treedec library).
* Additional general utility functions: qsort(), strtol(), strtoul().

Philipp Klaus Krause
SDCC 3.7.0 Release Manager

----------------------------------------------------------------------------
--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Reply via email to