Re: [Sdcc-user] Compiling SDCC with MSYS2/MINGW

[Maarten Brock <sourceforge.brock@ds...>]

Hello Stephen,

Please file a bug report (or several) in our bug tracker.

Maarten

> Hello Maarten,
> Thank you for pointing me towards looking at the driver's output more
> closely.
> I eventually narrowed things down. In sdcc/device/lib/pic16/configure.ac
> (and evidently in the corresponding configure script) we have
>
> line 60: AC_SUBST(CCAS, [\'$CCAS\'])
>
> This means that the build system determines CCAS to be /mingw64/bin/gpasm
> which is then wrapped in single quotes as '/mingw64/bin/gpasm' *before*
> other calls append an exe file extension. As a result the command is
> "'/mingw64/bin/gpasm'.exe "(double quotes excluded).
>
> In SDCCsystem.c:66 we have:
>   switch (*p)
>     {
>     case '\'':
> <snip>
>
> which is splitting the string into a command at the quotation mark as a
> delimiter, leaving .exe as part of the arguments.
>
> get_path in SDCCsystem.c:201 then adds an extra ".exe" onto our now
> extension-less command, which is then merged in with our arguments, so the
> compiler driver attempts to execute
>
> "/mingw64/bin/gpasm.exe .exe <options>" which obviously fails.
>
> Commenting out the AC_SUBST line in the pic14, pic16, and non-free pic16
> configure files allows compilation to succeed, with one small caveat:
> the driver also calls sdcpp.exe as part of compiling the pic14/16 device
> libraries -  sdcpp has just been built and is therefore not in the PATH.
> I have worked around this by temporarily setting the root sdcc source
> directory as SDCC_HOME, but evidently this is sub-optimal.
> Is there a way to tell sdcc it is being run during an SDCC compilation,
> and
> so it should look within its own folder? Should I be building SDCC in two
> stages instead?
> With regards to the commented lines - does wrapping the executable in
> single quotes serve a purpose? Is it worth me sending in a patch for the
> changes?
>
>
> Secondly, in my original post I indicated that STM8 support was building
> OK. Unfortunately this is not the case, but the build process doesn't
> error
> out.
>
> ../../../bin/sdar -rcD ../build/stm8/stm8.lib setjmp.rel _mulint.rel
> __mulsint2slong.rel _divsint.rel _modsint.rel _mullong.rel _divulong.rel
> _modulong.rel _divslong.rel _modslong.rel _fast_long_neg.rel heap.rel
> strcpy.rel strcmp.rel memcpy.rel _atof.rel _schar2fs.rel _sint2fs.rel
> _slong2fs.rel _uchar2fs.rel _uint2fs.rel _ulong2fs.rel _fs2schar.rel
> _fs2sint.rel _fs2slong.rel _fs2uchar.rel _fs2uint.rel _fs2ulong.rel
> _fsadd.rel _fsdiv.rel _fsmul.rel _fssub.rel _fseq.rel _fsgt.rel _fslt.rel
> _fsneq.rel fabsf.rel frexpf.rel ldexpf.rel expf.rel powf.rel sincosf.rel
> sinf.rel cosf.rel logf.rel log10f.rel sqrtf.rel tancotf.rel tanf.rel
> cotf.rel asincosf.rel asinf.rel acosf.rel atanf.rel atan2f.rel
> sincoshf.rel
> sinhf.rel coshf.rel tanhf.rel floorf.rel ceilf.rel modff.rel errno.rel
> isinf.rel isnan.rel _mulschar.rel _divschar.rel _modschar.rel
> _rrulonglong.rel _rrslonglong.rel _rlulonglong.rel _rlslonglong.rel
> _mullonglong.rel _divslonglong.rel _divulonglong.rel _modslonglong.rel
> _modulonglong.rel isalnum.rel isalpha.rel isblank.rel iscntrl.rel
> isdigit.rel isgraph.rel islower.rel isprint.rel ispunct.rel isspace.rel
> isupper.rel isxdigit.rel tolower.rel toupper.rel atoi.rel atol.rel
> atoll.rel abs.rel labs.rel rand.rel _strcat.rel _strchr.rel _strcspn.rel
> _strncat.rel _strncmp.rel strxfrm.rel _strncpy.rel _strpbrk.rel
> _strrchr.rel _strspn.rel _strstr.rel _strtok.rel _memchr.rel _memcmp.rel
> _memset.rel aligned_alloc.rel calloc.rel malloc.rel realloc.rel free.rel
> mblen.rel mbtowc.rel wctomb.rel mbstowcs.rel wcstombs.rel mbrtoc16.rel
> c16rtomb.rel mbrtoc32.rel c32rtomb.rel wcscmp.rel wcslen.rel btowc.rel
> wctob.rel mbsinit.rel mbrlen.rel mbrtowc.rel wcrtomb.rel printf_large.rel
> puts.rel gets.rel assert.rel time.rel _itoa.rel _ltoa.rel _startup.rel
> _strlen.rel _memmove.rel sprintf.rel vprintf.rel
> make[5]: *** [Makefile:66: ../build/stm8/stm8.lib] Segmentation fault
> make[5]: *** Deleting file '../build/stm8/stm8.lib'
> make[5]: Leaving directory '/c/source/sdcc/sdcc/device/lib/stm8'
> make[4]: [Makefile:408: port-specific-objects] Error 2 (ignored)
>
> <compilation continues>
>
> Through a process of elimination I was able to determine that the segfault
> is caused by any of the .rel files from _atof.rel onwards. For example:
>
> $ ../../../bin/sdar -rcD ../build/stm8/stm8.lib vprintf.rel
> Segmentation fault
>
> This looks similar to "#1903 compile of library file cause seg violation"
> (that one also mentions _atof.rel). Would you like me to raise a ticket
> for
> it, start another email thread (given the issues are both mingw related,
> but target different architectures) or shall we continue the discussion
> here alongside the other MINGW compilation issue?
>
> Thanks,
>
> Stephen
>
>
>
>
>
> On Mon, May 15, 2017 at 1:44 AM, Maarten Brock <sourceforge.brock@...>
> wrote:
>
>> > Hello everybody,
>> > Running into a strange issue trying to compile SDCC with the msys2
>> > environment.
>> > I've successfully downloaded gputils from source and compiled:
>> >
>> > $ gcc -v
>> >
>> >       <snip>
>> > gcc version 6.3.0 (Rev2, Built by MSYS2 project)
>> >                                                         $ gpasm -v
>> >
>> >                                                           gpasm-1.5.0
>> > #1285
>> > (Apr 28 2017)
>> >
>> > I configured SDCC using the following command line
>> >
>> > ./configure --disable-mcs51-port --disable-z80-port
>> --disable-z180-port
>> > --disable-r2k-port --disable-r3ka-port --disable-gbz80-port
>> > --disable-tlcs90-port --disable-ds390-port --disable-ds400-port
>> > --disable-hc08-port --disable-s08-port --disable-ucsim
>> > (essentially, enable stm8 and PIC but nothing else)
>> > STM8 and pic14 seem to build without errors, but it looks like
>> something
>> > in
>> > the pic16 lib is invoking gpasm incorrectly, as all of the 18f* file
>> > command lines result in the usage information for gpasm being printed
>> and
>> > the build consequently fails with missing object files.
>> > The error lines all have the following format:
>> >
>> > source='fake_sspbuf.c' object='libdev18f1220_a-fake_sspbuf.o'
>> libtool=no \
>> > DEPDIR=.deps depmode=none /bin/sh ../depcomp \
>> > '/c/source/sdcc/device/non-free/lib/pic16//../../../../bin/sdcc'
>> > -DHAVE_CONFIG_H -I. -I..  -I. -I../../../../include/pic16
>> > -I../../../../non-free/include/pic16  -p18f1220 --std-c99
>> > --asm="'/mingw64/bin/gpasm'" --no-warn-non-free --fomit-frame-pointer
>> > --obanksel=9 --denable-peeps --optimize-cmp --optimize-df
>> --i-code-in-asm
>> > -DUSE_FLOATS=0 -mpic16 -p18f452 -c -o libdev18f1220_a-fake_sspbuf.o
>> `test
>> > -f 'fake_sspbuf.c' || echo './'`fake_sspbuf.c
>> >
>> > Usage: gpasm [options] file
>> > Options: [defaults in brackets after descriptions]
>> >   -a FMT, --hex-format FMT       Select hex file format. [inhx32]
>> >   -c, --object                   Output relocatable object.
>> >  <gpasm usage info follows>
>> >
>> >
>> > Build fails much later with error:
>> > error: "libdev18f1220_a-pic18f1220.o" is not a valid object file
>> >
>> > Does anybody have any suggestions for how I can diagnose this?
>> > Thanks,
>> > Stephen
>>
>> Hello Stephen,
>>
>> Can you modify the makefile to make SDCC more verbose using --verbose ?
>> It
>> will print the way gpasm is called.
>>
>> Maarten
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> 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@...
>> 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@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>

Re: [Sdcc-user] Compiling SDCC with MSYS2/MINGW

[Stephen Whittle <twiddle87@gm...>]

Hello Maarten,
Thank you for pointing me towards looking at the driver's output more
closely.
I eventually narrowed things down. In sdcc/device/lib/pic16/configure.ac
(and evidently in the corresponding configure script) we have

line 60: AC_SUBST(CCAS, [\'$CCAS\'])

This means that the build system determines CCAS to be /mingw64/bin/gpasm
which is then wrapped in single quotes as '/mingw64/bin/gpasm' *before*
other calls append an exe file extension. As a result the command is
"'/mingw64/bin/gpasm'.exe "(double quotes excluded).

In SDCCsystem.c:66 we have:
  switch (*p)
    {
    case '\'':
<snip>

which is splitting the string into a command at the quotation mark as a
delimiter, leaving .exe as part of the arguments.

get_path in SDCCsystem.c:201 then adds an extra ".exe" onto our now
extension-less command, which is then merged in with our arguments, so the
compiler driver attempts to execute

"/mingw64/bin/gpasm.exe .exe <options>" which obviously fails.

Commenting out the AC_SUBST line in the pic14, pic16, and non-free pic16
configure files allows compilation to succeed, with one small caveat:
the driver also calls sdcpp.exe as part of compiling the pic14/16 device
libraries -  sdcpp has just been built and is therefore not in the PATH.
I have worked around this by temporarily setting the root sdcc source
directory as SDCC_HOME, but evidently this is sub-optimal.
Is there a way to tell sdcc it is being run during an SDCC compilation, and
so it should look within its own folder? Should I be building SDCC in two
stages instead?
With regards to the commented lines - does wrapping the executable in
single quotes serve a purpose? Is it worth me sending in a patch for the
changes?


Secondly, in my original post I indicated that STM8 support was building
OK. Unfortunately this is not the case, but the build process doesn't error
out.

../../../bin/sdar -rcD ../build/stm8/stm8.lib setjmp.rel _mulint.rel
__mulsint2slong.rel _divsint.rel _modsint.rel _mullong.rel _divulong.rel
_modulong.rel _divslong.rel _modslong.rel _fast_long_neg.rel heap.rel
strcpy.rel strcmp.rel memcpy.rel _atof.rel _schar2fs.rel _sint2fs.rel
_slong2fs.rel _uchar2fs.rel _uint2fs.rel _ulong2fs.rel _fs2schar.rel
_fs2sint.rel _fs2slong.rel _fs2uchar.rel _fs2uint.rel _fs2ulong.rel
_fsadd.rel _fsdiv.rel _fsmul.rel _fssub.rel _fseq.rel _fsgt.rel _fslt.rel
_fsneq.rel fabsf.rel frexpf.rel ldexpf.rel expf.rel powf.rel sincosf.rel
sinf.rel cosf.rel logf.rel log10f.rel sqrtf.rel tancotf.rel tanf.rel
cotf.rel asincosf.rel asinf.rel acosf.rel atanf.rel atan2f.rel sincoshf.rel
sinhf.rel coshf.rel tanhf.rel floorf.rel ceilf.rel modff.rel errno.rel
isinf.rel isnan.rel _mulschar.rel _divschar.rel _modschar.rel
_rrulonglong.rel _rrslonglong.rel _rlulonglong.rel _rlslonglong.rel
_mullonglong.rel _divslonglong.rel _divulonglong.rel _modslonglong.rel
_modulonglong.rel isalnum.rel isalpha.rel isblank.rel iscntrl.rel
isdigit.rel isgraph.rel islower.rel isprint.rel ispunct.rel isspace.rel
isupper.rel isxdigit.rel tolower.rel toupper.rel atoi.rel atol.rel
atoll.rel abs.rel labs.rel rand.rel _strcat.rel _strchr.rel _strcspn.rel
_strncat.rel _strncmp.rel strxfrm.rel _strncpy.rel _strpbrk.rel
_strrchr.rel _strspn.rel _strstr.rel _strtok.rel _memchr.rel _memcmp.rel
_memset.rel aligned_alloc.rel calloc.rel malloc.rel realloc.rel free.rel
mblen.rel mbtowc.rel wctomb.rel mbstowcs.rel wcstombs.rel mbrtoc16.rel
c16rtomb.rel mbrtoc32.rel c32rtomb.rel wcscmp.rel wcslen.rel btowc.rel
wctob.rel mbsinit.rel mbrlen.rel mbrtowc.rel wcrtomb.rel printf_large.rel
puts.rel gets.rel assert.rel time.rel _itoa.rel _ltoa.rel _startup.rel
_strlen.rel _memmove.rel sprintf.rel vprintf.rel
make[5]: *** [Makefile:66: ../build/stm8/stm8.lib] Segmentation fault
make[5]: *** Deleting file '../build/stm8/stm8.lib'
make[5]: Leaving directory '/c/source/sdcc/sdcc/device/lib/stm8'
make[4]: [Makefile:408: port-specific-objects] Error 2 (ignored)

<compilation continues>

Through a process of elimination I was able to determine that the segfault
is caused by any of the .rel files from _atof.rel onwards. For example:

$ ../../../bin/sdar -rcD ../build/stm8/stm8.lib vprintf.rel
Segmentation fault

This looks similar to "#1903 compile of library file cause seg violation"
(that one also mentions _atof.rel). Would you like me to raise a ticket for
it, start another email thread (given the issues are both mingw related,
but target different architectures) or shall we continue the discussion
here alongside the other MINGW compilation issue?

Thanks,

Stephen





On Mon, May 15, 2017 at 1:44 AM, Maarten Brock <sourceforge.brock@...>
wrote:

> > Hello everybody,
> > Running into a strange issue trying to compile SDCC with the msys2
> > environment.
> > I've successfully downloaded gputils from source and compiled:
> >
> > $ gcc -v
> >
> >       <snip>
> > gcc version 6.3.0 (Rev2, Built by MSYS2 project)
> >                                                         $ gpasm -v
> >
> >                                                           gpasm-1.5.0
> > #1285
> > (Apr 28 2017)
> >
> > I configured SDCC using the following command line
> >
> > ./configure --disable-mcs51-port --disable-z80-port --disable-z180-port
> > --disable-r2k-port --disable-r3ka-port --disable-gbz80-port
> > --disable-tlcs90-port --disable-ds390-port --disable-ds400-port
> > --disable-hc08-port --disable-s08-port --disable-ucsim
> > (essentially, enable stm8 and PIC but nothing else)
> > STM8 and pic14 seem to build without errors, but it looks like something
> > in
> > the pic16 lib is invoking gpasm incorrectly, as all of the 18f* file
> > command lines result in the usage information for gpasm being printed and
> > the build consequently fails with missing object files.
> > The error lines all have the following format:
> >
> > source='fake_sspbuf.c' object='libdev18f1220_a-fake_sspbuf.o'
> libtool=no \
> > DEPDIR=.deps depmode=none /bin/sh ../depcomp \
> > '/c/source/sdcc/device/non-free/lib/pic16//../../../../bin/sdcc'
> > -DHAVE_CONFIG_H -I. -I..  -I. -I../../../../include/pic16
> > -I../../../../non-free/include/pic16  -p18f1220 --std-c99
> > --asm="'/mingw64/bin/gpasm'" --no-warn-non-free --fomit-frame-pointer
> > --obanksel=9 --denable-peeps --optimize-cmp --optimize-df --i-code-in-asm
> > -DUSE_FLOATS=0 -mpic16 -p18f452 -c -o libdev18f1220_a-fake_sspbuf.o `test
> > -f 'fake_sspbuf.c' || echo './'`fake_sspbuf.c
> >
> > Usage: gpasm [options] file
> > Options: [defaults in brackets after descriptions]
> >   -a FMT, --hex-format FMT       Select hex file format. [inhx32]
> >   -c, --object                   Output relocatable object.
> >  <gpasm usage info follows>
> >
> >
> > Build fails much later with error:
> > error: "libdev18f1220_a-pic18f1220.o" is not a valid object file
> >
> > Does anybody have any suggestions for how I can diagnose this?
> > Thanks,
> > Stephen
>
> Hello Stephen,
>
> Can you modify the makefile to make SDCC more verbose using --verbose ? It
> will print the way gpasm is called.
>
> Maarten
>
>
>
> ------------------------------------------------------------
> ------------------
> 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@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>

Re: [Sdcc-user] Compiling SDCC with MSYS2/MINGW

[Maarten Brock <sourceforge.brock@ds...>]

> Hello everybody,
> Running into a strange issue trying to compile SDCC with the msys2
> environment.
> I've successfully downloaded gputils from source and compiled:
>
> $ gcc -v
>
>       <snip>
> gcc version 6.3.0 (Rev2, Built by MSYS2 project)
>                                                         $ gpasm -v
>
>                                                           gpasm-1.5.0
> #1285
> (Apr 28 2017)
>
> I configured SDCC using the following command line
>
> ./configure --disable-mcs51-port --disable-z80-port --disable-z180-port
> --disable-r2k-port --disable-r3ka-port --disable-gbz80-port
> --disable-tlcs90-port --disable-ds390-port --disable-ds400-port
> --disable-hc08-port --disable-s08-port --disable-ucsim
> (essentially, enable stm8 and PIC but nothing else)
> STM8 and pic14 seem to build without errors, but it looks like something
> in
> the pic16 lib is invoking gpasm incorrectly, as all of the 18f* file
> command lines result in the usage information for gpasm being printed and
> the build consequently fails with missing object files.
> The error lines all have the following format:
>
> source='fake_sspbuf.c' object='libdev18f1220_a-fake_sspbuf.o' libtool=no \
> DEPDIR=.deps depmode=none /bin/sh ../depcomp \
> '/c/source/sdcc/device/non-free/lib/pic16//../../../../bin/sdcc'
> -DHAVE_CONFIG_H -I. -I..  -I. -I../../../../include/pic16
> -I../../../../non-free/include/pic16  -p18f1220 --std-c99
> --asm="'/mingw64/bin/gpasm'" --no-warn-non-free --fomit-frame-pointer
> --obanksel=9 --denable-peeps --optimize-cmp --optimize-df --i-code-in-asm
> -DUSE_FLOATS=0 -mpic16 -p18f452 -c -o libdev18f1220_a-fake_sspbuf.o `test
> -f 'fake_sspbuf.c' || echo './'`fake_sspbuf.c
>
> Usage: gpasm [options] file
> Options: [defaults in brackets after descriptions]
>   -a FMT, --hex-format FMT       Select hex file format. [inhx32]
>   -c, --object                   Output relocatable object.
>  <gpasm usage info follows>
>
>
> Build fails much later with error:
> error: "libdev18f1220_a-pic18f1220.o" is not a valid object file
>
> Does anybody have any suggestions for how I can diagnose this?
> Thanks,
> Stephen

Hello Stephen,

Can you modify the makefile to make SDCC more verbose using --verbose ? It
will print the way gpasm is called.

Maarten

Re: [Sdcc-user] Tutorials for STM8 and MCS-51 development using the Small Device C Compiler for various boards

[Maarten Brock <sourceforge.brock@ds...>]

> Based on my experience in getting started with various STM8 and MCS-51
> boards, I wrote a few simple tutorials to help others. They use free
> tools only. For various evaluation boards there are three simple demos:
>
> 1) LED counter controlled by timer
> 2) Serial output
> 3) Dhrystone / Whetstone benchmarks
>
> The tutorials can be found at:
>
> http://www.colecovision.eu/stm8/
> http://www.colecovision.eu/mcs51/
>
> Please tell me if you find any mistakes, or have any suggestions for
> improvement.
>
> Philipp

Hi Philipp,

On the C8051F120 Dhrystone page you write:
The C8051F120 itself could run at up to 100 Mhz, but would require an
external crystal to do so.

This is not true. You can also use the PLL on the internal 24.5MHz +/-2%
oscillator giving 98MHz +/-2%.

Maarten

Re: [Sdcc-user] overloading functions (weak)?

[<icking@on...>]

>> apparently it is possible to overload functions in SDCC for STM8, as
>> shown recently in the getchar() implementation in one of the previous
>> mails. Is this something that can also be done with C routines in a
>> project? If yes, is there something like a "__weak" attribute to tell
>> the linker which function to use?
> 'Overloading' can only be done for functions that reside in a library. The
> linker will first link all sources (actually .rel files a.k.a. objects) it
> was given and after that it will search missing symbols in the libraries.
> So if you provide getchar() in your sources there is no need to search for
> it in the libraries and yours will be used.
>
> This also means that all code in your object files is linked in whether
> it's used or not. And objects in the libraries that are not referenced are
> not linked in. Also note that all functions in an object are linked in,
> not just the missing one.
>
> Maarten

hello Maarten,

thanks (again) for your very good and understandable explanation and 
have a nice weekend! :-)

Georg

Re: [Sdcc-user] binary constants for STM8?

[<icking@on...>]

>> in the SDCC manual I read "SDCC supports the use of binary constants,
>> such as 0b01100010. This feature is only enabled when the compiler is
>> invoked using ???std-sdccxx"
>>
>> However, calling SDCC for stm8 with ???std-sdccxx fails with "syntax
>> error" for the literal and a warning that "option '-s' no longer
>> supported". And caliing it with -???std-sdccxx gives the same syntax error
>> and a warning "unknown compiler option '--std-sdccxx' ignored".
>>
>> Does this mean that binary literals are not yet implemented for STM8...?
>> If they are, please let me know how to use them.
>>
>> Thanks in advance!
>>
>> Regards, Georg
> Hello Georg,
>
> You are kindly requested to replace the XX in --std-sdccXX with the year
> of the C standard you wish to use. E.g. --std-sdcc99.
>
> Further you seem to use different dashes before std.
>
> Maarten

hello Maarten,

thanks a lot for your help - how stupid of me not to see that! However 
my problem was that sdcc was called with both "--std-sdcc99" and 
"--std-c99" (in that order). Removing the latter did the job :-)

Georg

Re: [Sdcc-user] Anyone using --nojtbound or #pragma nojtbound?

[Andrea Rossetti <andrea.rossetti@gm...>]

Philipp Klaus Krause <pkk-dH2bkuHepfc@...> writes:
> Do the option --nojtbound and the #pragma nojtbound have any users?
>...
> If the option and pragma do not have users, we might want to remove it.

Recently I had been confused by its name starting with "--no...." and
used it the opposite way that I intended (disable all optimizations).
Re-reading the docs cleared doubts, apologies for having reported a
non-existent bug about it.

I believe it may still be useful in careful hands, maybe renamed to
"--enable-unsafe-skipjtbound" or similar, a name that conveys the fact
that:

- optimization is off by default
- optimization is "unsafe" if turned on, i.e. not all legitimate C
  code is compatible with it

On the other side it's probably some maintainance and documentation
burden for modest benefits, so I won't object if it gets removed.

Cheers, 

Andrea

[Sdcc-user] Anyone using --nojtbound or #pragma nojtbound?

[Philipp Klaus Krause <pkk@sp...>]

Do the option --nojtbound and the #pragma nojtbound have any users?

The option enables a bit of extra optimizations on some switch
statements by making all cases not covered by explicit case statements
undefined behaviour.

If the option and pragma do not have users, we might want to remove it.

Philipp

Re: [Sdcc-user] binary constants for STM8?

[Maarten Brock <sourceforge.brock@ds...>]

> again hello,
>
> in the SDCC manual I read "SDCC supports the use of binary constants,
> such as 0b01100010. This feature is only enabled when the compiler is
> invoked using –std-sdccxx"
>
> However, calling SDCC for stm8 with –std-sdccxx fails with "syntax
> error" for the literal and a warning that "option '-s' no longer
> supported". And caliing it with -–std-sdccxx gives the same syntax error
> and a warning "unknown compiler option '--std-sdccxx' ignored".
>
> Does this mean that binary literals are not yet implemented for STM8...?
> If they are, please let me know how to use them.
>
> Thanks in advance!
>
> Regards, Georg

Hello Georg,

You are kindly requested to replace the XX in --std-sdccXX with the year
of the C standard you wish to use. E.g. --std-sdcc99.

Further you seem to use different dashes before std.

Maarten

Re: [Sdcc-user] overloading functions (weak)?

[Maarten Brock <sourceforge.brock@ds...>]

> hello all,
>
> apparently it is possible to overload functions in SDCC for STM8, as
> shown recently in the getchar() implementation in one of the previous
> mails. Is this something that can also be done with C routines in a
> project? If yes, is there something like a "__weak" attribute to tell
> the linker which function to use?
>
> Thanks a lot in advance!
>
> Regards, Georg

Hello Georg,

'Overloading' can only be done for functions that reside in a library. The
linker will first link all sources (actually .rel files a.k.a. objects) it
was given and after that it will search missing symbols in the libraries.
So if you provide getchar() in your sources there is no need to search for
it in the libraries and yours will be used.

This also means that all code in your object files is linked in whether
it's used or not. And objects in the libraries that are not referenced are
not linked in. Also note that all functions in an object are linked in,
not just the missing one.

Maarten

[Sdcc-user] binary constants for STM8?

[Georg Icking-Konert <georg@cr...>]

again hello,

in the SDCC manual I read "SDCC supports the use of binary constants, 
such as 0b01100010. This feature is only enabled when the compiler is 
invoked using –std-sdccxx"

However, calling SDCC for stm8 with –std-sdccxx fails with "syntax 
error" for the literal and a warning that "option '-s' no longer 
supported". And caliing it with -–std-sdccxx gives the same syntax error 
and a warning "unknown compiler option '--std-sdccxx' ignored".

Does this mean that binary literals are not yet implemented for STM8...? 
If they are, please let me know how to use them.

Thanks in advance!

Regards, Georg

[Sdcc-user] overloading functions (weak)?

[Georg Icking-Konert <georg@cr...>]

hello all,

apparently it is possible to overload functions in SDCC for STM8, as 
shown recently in the getchar() implementation in one of the previous 
mails. Is this something that can also be done with C routines in a 
project? If yes, is there something like a "__weak" attribute to tell 
the linker which function to use?

Thanks a lot in advance!

Regards, Georg

Re: [Sdcc-user] Change between 9880 and 9889 In Peephole Application?

[alvin albrecht <alvin_albrecht@ho...>]

Of course I found the problem in the very next thing I checked.

The patch applied for https://sourceforge.net/p/sdcc/bugs/2600/
is incorrect and I will file there shortly.

[Sdcc-user] Change between 9880 and 9889 In Peephole Application?

[alvin albrecht <alvin_albrecht@ho...>]

I’m seeing some odd behaviour in a change from 9880 to 9889 where some peephole rules are applied while others are not for user supplied peephole rules on a z80 target.

The sdcc invoke uses the form:  “--no-peep --peep-file peep.def”.  Some rules are applied and others are not.

The results we see are compiled binaries that are several kb larger.

Can anyone think of something specific in there that might cause such behaviour?  I’m still investigating so if I find it I will write back.

Re: [Sdcc-user] Local variable in mixed asm/c vs compiler warning

[Marco Peereboom <slash@pe...>]

> 
> Maybe you can tell us what warning you get that you want to get rid of?

I am sorry about.
i8251.c:28: warning 59: function 'getchar' must return value

> 
> That being said, when the complete function is written in asm you probably
> want to use the __naked keyword to suppress the red tape.

And that does exactly what I wanted!  Thank you.

Did I miss this in the documentation?

Re: [Sdcc-user] Local variable in mixed asm/c vs compiler warning

[Maarten Brock <sourceforge.brock@ds...>]

> Consider the following snippet:
>
> // override getchar from stdlib
> int
> getchar(void)
> {
> __asm
> l1:    in      a,(I8251_STATUS)        // get status
>        and     #I8251_S_RXRDY          // check RxRDY bit
>        jp      z,l1                    // not ready, loop
>        in      a,(I8251_DATA)          // get char
>        ld      h,#0                    // reset high return value
>        ld      l,a                     // set low return value
> __endasm;
>        // we eat the warning to save 3 bytes.
> }
>
> Get’s compiled into:
> ; Function getchar
> ; ---------------------------------
> _getchar::
> ;i8251.c:28: __endasm;
>        l1:
>        in a,(((0x02) + 1))
>        and     #(1<<1)
>        jp      z,l1
>        in      a,(((0x02) ))
>        ld      h,#0
>        ld      l,a
>        ret
>
> Which is exactly what I want but the compiler complains.  I have seen
> some solutions where it is suggested to put the code in an asm file
> instead but I was wondering if there is a #pragma or something else
> I can use to in this specific case to shut the compiler warning up?
>
> Loading a into a local variable works too but it is more code as well.
> I am just wondering what the best practices are for these types of
> mixed asm/c are with sdcc.
>
> /marco

Maybe you can tell us what warning you get that you want to get rid of?

That being said, when the complete function is written in asm you probably
want to use the __naked keyword to suppress the red tape.

Maarten

[Sdcc-user] Local variable in mixed asm/c vs compiler warning

[Marco Peereboom <marco@pe...>]

Consider the following snippet:

// override getchar from stdlib
int
getchar(void)
{
__asm
l1:    in      a,(I8251_STATUS)        // get status
       and     #I8251_S_RXRDY          // check RxRDY bit
       jp      z,l1                    // not ready, loop
       in      a,(I8251_DATA)          // get char
       ld      h,#0                    // reset high return value
       ld      l,a                     // set low return value
__endasm;
       // we eat the warning to save 3 bytes.
}

Get’s compiled into:
; Function getchar
; ---------------------------------
_getchar::
;i8251.c:28: __endasm;
       l1:
       in a,(((0x02) + 1))
       and     #(1<<1)
       jp      z,l1
       in      a,(((0x02) ))
       ld      h,#0
       ld      l,a
       ret

Which is exactly what I want but the compiler complains.  I have seen
some solutions where it is suggested to put the code in an asm file
instead but I was wondering if there is a #pragma or something else
I can use to in this specific case to shut the compiler warning up?

Loading a into a local variable works too but it is more code as well.
I am just wondering what the best practices are for these types of
mixed asm/c are with sdcc.

/marco

[Sdcc-user] Compiling SDCC with MSYS2/MINGW

[Stephen Whittle <twiddle87@gm...>]

Hello everybody,
Running into a strange issue trying to compile SDCC with the msys2
environment.
I've successfully downloaded gputils from source and compiled:

$ gcc -v

      <snip>
gcc version 6.3.0 (Rev2, Built by MSYS2 project)
                                                        $ gpasm -v

                                                          gpasm-1.5.0 #1285
(Apr 28 2017)

I configured SDCC using the following command line

./configure --disable-mcs51-port --disable-z80-port --disable-z180-port
--disable-r2k-port --disable-r3ka-port --disable-gbz80-port
--disable-tlcs90-port --disable-ds390-port --disable-ds400-port
--disable-hc08-port --disable-s08-port --disable-ucsim
(essentially, enable stm8 and PIC but nothing else)
STM8 and pic14 seem to build without errors, but it looks like something in
the pic16 lib is invoking gpasm incorrectly, as all of the 18f* file
command lines result in the usage information for gpasm being printed and
the build consequently fails with missing object files.
The error lines all have the following format:

source='fake_sspbuf.c' object='libdev18f1220_a-fake_sspbuf.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
'/c/source/sdcc/device/non-free/lib/pic16//../../../../bin/sdcc'
-DHAVE_CONFIG_H -I. -I..  -I. -I../../../../include/pic16
-I../../../../non-free/include/pic16  -p18f1220 --std-c99
--asm="'/mingw64/bin/gpasm'" --no-warn-non-free --fomit-frame-pointer
--obanksel=9 --denable-peeps --optimize-cmp --optimize-df --i-code-in-asm
-DUSE_FLOATS=0 -mpic16 -p18f452 -c -o libdev18f1220_a-fake_sspbuf.o `test
-f 'fake_sspbuf.c' || echo './'`fake_sspbuf.c

Usage: gpasm [options] file
Options: [defaults in brackets after descriptions]
  -a FMT, --hex-format FMT       Select hex file format. [inhx32]
  -c, --object                   Output relocatable object.
 <gpasm usage info follows>


Build fails much later with error:
error: "libdev18f1220_a-pic18f1220.o" is not a valid object file

Does anybody have any suggestions for how I can diagnose this?
Thanks,
Stephen

Re: [Sdcc-user] New STM8 OpenOCD and gdb debugger available

[Травкин Роман <ramon13666@ya...>]

<div>Nice to hear about work you've done.</div><div> </div><div> </div>

Re: [Sdcc-user] New STM8 OpenOCD and gdb debugger available

[Åke Rehnman <ake.rehnman@gm...>]

Hola Diego,

as for the openocd the plan is to get the stm8 target merged upstream as 
soon as the code gets reviewed.

Regarding sdcc it is basically a big ugly hack to get it to play ball 
with the inner workings of gdb. Hopefully sdcc will get proper dwarf 
debugger tables implemented soon so sdcc will work without my patches.

/Åke


On 2017-03-06 20:44, Diego Herranz wrote:
> Sounds interesting, thanks for letting us know.
>
> Any plans on submitting your changes to the different upstream 
> projects (OpenOCD, SDCC, etc.)? Any reason not to?
>
> Cheers,
> Diego
>
> On Mon, Mar 6, 2017 at 1:34 PM, Åke Rehnman <ake.rehnman@... 
> <mailto:ake.rehnman@...>> wrote:
>
>     For all interested in STM8 and gdb debugger I hereby announce the
>     stm8-binutils-gdb project hosted at SourceForge.
>
>     Check it out at https://stm8-binutils-gdb.sourceforge.io/
>     <https://stm8-binutils-gdb.sourceforge.io/>;
>
>     The project contains a complete toolchain for STM8 with updated and
>     patched versions of:
>
>     gdb 7.12.1
>     binutils 2.27
>     openocd 0.10.0
>     sdcc 3.6.0
>
>     Happy hacking.
>
>     /Åke
>
>
>     ------------------------------------------------------------------------------
>     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@...
>     <mailto:Sdcc-user@...>
>     https://lists.sourceforge.net/lists/listinfo/sdcc-user
>     <https://lists.sourceforge.net/lists/listinfo/sdcc-user>;
>
>
>
>
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
>
>
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] New STM8 OpenOCD and gdb debugger available

[Diego Herranz <diegoherranz@di...>]

Sounds interesting, thanks for letting us know.

Any plans on submitting your changes to the different upstream projects
(OpenOCD, SDCC, etc.)? Any reason not to?

Cheers,
Diego

On Mon, Mar 6, 2017 at 1:34 PM, Åke Rehnman <ake.rehnman@...> wrote:

> For all interested in STM8 and gdb debugger I hereby announce the
> stm8-binutils-gdb project hosted at SourceForge.
>
> Check it out at https://stm8-binutils-gdb.sourceforge.io/
>
> The project contains a complete toolchain for STM8 with updated and
> patched versions of:
>
> gdb 7.12.1
> binutils 2.27
> openocd 0.10.0
> sdcc 3.6.0
>
> Happy hacking.
>
> /Åke
>
>
> ------------------------------------------------------------
> ------------------
> 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@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>

[Sdcc-user] New STM8 OpenOCD and gdb debugger available

[Åke Rehnman <ake.rehnman@gm...>]

For all interested in STM8 and gdb debugger I hereby announce the 
stm8-binutils-gdb project hosted at SourceForge.

Check it out at https://stm8-binutils-gdb.sourceforge.io/

The project contains a complete toolchain for STM8 with updated and 
patched versions of:

gdb 7.12.1
binutils 2.27
openocd 0.10.0
sdcc 3.6.0

Happy hacking.

/Åke

Re: [Sdcc-user] Tutorials for STM8 and MCS-51 development using the Small Device C Compiler for various boards

[Augusto Fraga Giachero <augustofg96@gm...>]

I haven't received any email from you (I've checked my Spam folder).

Augusto F. Giachero

On 21-02-2017 16:34, Miklos Marton wrote:
> Hi there,
>
> I have sent you a separate mail about the gitlab stuff about branches &
> PRs.
>
> If you have some time please check that! Thanks!
>
> Best regards,
> Miklos Marton
>
> 2017-02-21 19:56 keltezéssel, Augusto Fraga Giachero írta:
>> Nice!
>>
>>
>> On 14-02-2017 16:26, Miklos Marton wrote:
>>>> I've found an recent post on ST forums that has a link to an old version
>>>> of the GDB source code modified by ST to support STM8 targets. I've
>>>> uploaded to GitLab for convenience. Maybe one day I'll try to compile it.
>>>>
>>>> Here is the link for the git repository:
>>>> https://gitlab.com/Palmitoxico/stm8-gdb/tree/master
>>>>
>>>> Augusto F. Giachero
>>>>
>>> In the case if anyone is interested:
>>> I have managed to get the gdb sources from a guy who got it from ST
>>> directly of the currently shipping STM8 GDB (it uses ST7 v3.10.2
>>> internal version).
>>> There are many changes between the publicly available (v3.9.16) and this
>>> version.
>>>
>>> https://gitlab.com/martonmiklos/stm8-gdb/tree/v3.10.2
>>>
>>> Best regards,
>>> Miklos Marton
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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@...
>>> 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@...
>> 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@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] Tutorials for STM8 and MCS-51 development using the Small Device C Compiler for various boards

[Miklos Marton <martonmiklosqdev@gm...>]

Hi there,

I have sent you a separate mail about the gitlab stuff about branches & 
PRs.

If you have some time please check that! Thanks!

Best regards,
Miklos Marton

2017-02-21 19:56 keltezéssel, Augusto Fraga Giachero írta:
> Nice!
>
>
> On 14-02-2017 16:26, Miklos Marton wrote:
>>> I've found an recent post on ST forums that has a link to an old version
>>> of the GDB source code modified by ST to support STM8 targets. I've
>>> uploaded to GitLab for convenience. Maybe one day I'll try to compile it.
>>>
>>> Here is the link for the git repository:
>>> https://gitlab.com/Palmitoxico/stm8-gdb/tree/master
>>>
>>> Augusto F. Giachero
>>>
>> In the case if anyone is interested:
>> I have managed to get the gdb sources from a guy who got it from ST
>> directly of the currently shipping STM8 GDB (it uses ST7 v3.10.2
>> internal version).
>> There are many changes between the publicly available (v3.9.16) and this
>> version.
>>
>> https://gitlab.com/martonmiklos/stm8-gdb/tree/v3.10.2
>>
>> Best regards,
>> Miklos Marton
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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@...
>> 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@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>

Re: [Sdcc-user] Tutorials for STM8 and MCS-51 development using the Small Device C Compiler for various boards

[Augusto Fraga Giachero <augustofg96@gm...>]

Nice!


On 14-02-2017 16:26, Miklos Marton wrote:
>> I've found an recent post on ST forums that has a link to an old version
>> of the GDB source code modified by ST to support STM8 targets. I've
>> uploaded to GitLab for convenience. Maybe one day I'll try to compile it.
>>
>> Here is the link for the git repository:
>> https://gitlab.com/Palmitoxico/stm8-gdb/tree/master
>>
>> Augusto F. Giachero
>>
> In the case if anyone is interested:
> I have managed to get the gdb sources from a guy who got it from ST
> directly of the currently shipping STM8 GDB (it uses ST7 v3.10.2
> internal version).
> There are many changes between the publicly available (v3.9.16) and this
> version.
>
> https://gitlab.com/martonmiklos/stm8-gdb/tree/v3.10.2
>
> Best regards,
> Miklos Marton
>
>
>
> ------------------------------------------------------------------------------
> 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@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user