Re: [Sdcc-user] uCsim for STM8 question (0.6-pre28)

[Daniel Drotos <drdani@ma...>]

On Sat, 10 Jun 2017, Thomas Goeppel wrote:

> * Is there a "trace" feature in uCsim? Some use cases would greatly benefit 
> from a trace/log of all the executed instructions, e.g. between two triggers.

No (officialy), but there is a hidden/secret feature which works like 
this:-)

If you start ucsim with -J option, trace will be turned on, and 
_every_ instruction will print out cpu state like "info reg".

Tracing can be checked and turned on/off using "jaj" command which 
accepts a boolean parameter:

$ ./sstm8
uCsim 0.6-pre30, Copyright (C) 1997 Daniel Drotos.
uCsim comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
0> jaj
0
0> s 100
Stop at 0x0080c8: (109)
V-IHINZC  Flags= 0x2d  45 -  A= 0x00   0 .
0-101101  X= 0x0000   0 .    Y= 0x0000   0 .
SP= 0x17ff [SP+1]= 00   0 .
  ? 0x080c8 00 00          neg   (0x00,SP)
F 0x0080c8
Simulated 100 ticks in 0.000044 sec, rate=0.284939
0> jaj 1
1
0> s 2
V-IHINZC  Flags= 0x29  41 )  A= 0x00   0 .
0-101001  X= 0x0000   0 .    Y= 0x0000   0 .
SP= 0x17ff [SP+1]= 00   0 .
  ? 0x080ca 00 00          neg   (0x00,SP)

Stop at 0x0080cc: (109)
V-IHINZC  Flags= 0x2d  45 -  A= 0x00   0 .
0-101101  X= 0x0000   0 .    Y= 0x0000   0 .
SP= 0x17ff [SP+1]= 00   0 .
  ? 0x080cc 00 00          neg   (0x00,SP)
F 0x0080cc
Simulated 2 ticks in 0.000046 sec, rate=0.005433
0>

Daniel

[Sdcc-user] structs, array of structs, declaring and using, memory bank boundary, timers

[Ubirajara Marques da Cruz <biracruz@ce...>]

Hi all,

I´ve been trying to implement TDC(time delay close) and TDO (time delay open) contact relays into pic program and I am facing some trouble that I need to clarify. I am working with pic 16f877a and SDCC 3.6. I´m not an assembler programmer only C programmer.

What my program need to do.
It need to charge datas asynchronous event time into an array of timer event structures, sequences it, and order fastest event to slowest and change output relay into right time. I plan to use only one  pic timer to do this and I can have until 6 time contact relays.

1st) About struct
I created a typedef struct tmrevent that holds 5 int members to hold TMR1H, TMR1L, overflowtimertimes and another int datas. Into Gcc this array could be done like this:

Typedef struct tmrevent {
int member1;
int member2;
...
int member;
};

tmrevent  tv[4];

this code in Gcc works fine and I have an array of tmrevent struct with 4 structs. But in SDCC this code compiles but doesn't link. Why?
Is there another way to define an array of structs in SDCC? Could you tell me pls?

2nd) If I address only one struct my code works but I must declare it like an array like below and only one array element is possible to use. My sdcc installation doesn´t have MALLOC.H header file to declare a space to hold many struct in a pointer.

__at(0x0020) tmrevent tv[]; // compiles and linker but only one element works

3rd) I read sdcc 3.6.1 manual item 3.1.1 (only this item talk about structures in manual ) but I can´t clarify much about how structs could be declare with sdcc. Could you inform some book or tutorial that cover this subject. I will appreciate a lot.

4th) I did a test declaring many separate timer event structs addressing directly all of them respecting GPIO addressable memory. I try to use more than a memory bank and another problem occurs. It seems bank 1 is mirrored of bank 0. I found some posts that tell about this condition but none explain how to use direct address to write member structs in the correct bank. For example if I declare a struct in address 0x0020 (first gpio in bank 0 ) the code works fine. If I declare this struct into address 0x00A0 (first gpio in bank 1) sometimes the code works sometimes don´t. What could be? It seems when program counter is on bank 1 or bank 2 or 3 and interrupt overflow time occurs data that will be record in bank 0 isn´t correctly write. But in SDCC I didn´t find any example to solve this doubt.

I will appreciate a lot some answer.

Thank you all

Ubirajara Marques da Cruz
Email: biracruz@...<mailto:biracruz@...>

As informações contidas nesta mensagem e nos arquivos anexados são para uso exclusivo do destinatário aqui indicado e podem conter assuntos comerciais, de propriedade intelectual ou outras informações confidenciais, protegidas pelas leis aplicáveis. É expressamente proibido o uso não autorizado ou a disseminação desta mensagem ou parte dela. Caso não seja o destinatário correto, por favor, notifique o remetente.

Re: [Sdcc-user] Can't figure out how to write interrupt handlers for Z80 using SDCC

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

> but can't figure out how to use the above example crt0.s file with SDCC for a Z80 target. Using the --use-crt switch doesn't seem to work.
> unknown compiler option '--use-crt=crt0.s' ignored

Have a look here for an example of using a custom crt.s:
https://github.com/z88dk/z88dk/tree/master/libsrc/_DEVELOPMENT/EXAMPLES/benchmarks/dhrystone21/sdcc/verify

Read Winmake.bat to see how the program is compiled.

Re: [Sdcc-user] Can't figure out how to write interrupt handlers for Z80 using SDCC

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

Hello Adam,

I think you're supposed to take our crt.s and modifiy it to your needs
with the missing jumps.
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/device/lib/z80/crt0.s

Assemble it and then link it with the rest of your application.

Maarten

> Hi,
>
> I'm developing a program in C for the Z80 and compiling using SDCC. I
> can't
> figure out how to create interrupt handlers for the NMI interrupt that
> starts at 0x0066 and the IM1 interrupt that starts at 0x0038. I'm using
> these calls:
>
> void IM1_InterruptHandler(void) __interrupt
> and
> void NMI_InterruptHandler (void) __critical __interrupt
>
> and the resulting assembly looks about right but they aren't located at
> the proper addresses. I did spot this thread:
>
> https://sourceforge.net/p/sdcc/feature-requests/519/
>
> but can't figure out how to use the above example crt0.s file with SDCC
> for a Z80 target. Using the --use-crt switch doesn't seem to work.
>
> unknown compiler option '--use-crt=crt0.s' ignored
>
> Anyone experienced with Z80 development with SDCC that can provide some
> guidance?
> Perhaps I'm doing something incorrectly.
>
> Thanks!
> -Adam

[Sdcc-user] Can't figure out how to write interrupt handlers for Z80 using SDCC

[Adam Courchesne <ajcrm125@gm...>]

Hi,

I'm developing a program in C for the Z80 and compiling using SDCC. I can't
figure out how to create interrupt handlers for the NMI interrupt that
starts at 0x0066 and the IM1 interrupt that starts at 0x0038. I'm using
these calls:

void IM1_InterruptHandler(void) __interrupt
and
void NMI_InterruptHandler (void) __critical __interrupt

and the resulting assembly looks about right but they aren't located at the
proper addresses. I did spot this thread:

https://sourceforge.net/p/sdcc/feature-requests/519/

but can't figure out how to use the above example crt0.s file with SDCC for
a Z80 target. Using the --use-crt switch doesn't seem to work.

unknown compiler option '--use-crt=crt0.s' ignored

Anyone experienced with Z80 development with SDCC that can provide some
guidance?
Perhaps I'm doing something incorrectly.

Thanks!
-Adam
"Please don't judge my God by my inability to follow him"  - Chris Mollins
===============
 http://www.onecircuit.com
 http://www.mapleridge.net
===============

Re: [Sdcc-user] eZ80 support

[Hynek Sladky <econf@ce...>]

Hello,

I succesfully used compiler/linker from ZDS on linux (ZDS is now free; 
makefile based project; exe called through wine). I don't know another 
possibility for eZ80 compiler. I played a bit with flashing/debugging 
(https://hackaday.io/project/9483-ez80-open-source-programmer) but 
unfortunately nothing ready to use.
I can imagine to use SDCC for eZ80 but app will be limited to 64K and 
there could be problem accessing built-in peripherals (it will need 
using new instructions).

BR,
Hynek


Dne 11.5.2017 2:51, Bennett Ramirez napsal(a):
> Hello,
>
> I'm wondering if the eZ80F91 is a supported target for SDCC. I am
> seeking a cross-platform alternative to ZDS, which is really geared
> toward development from a Windows machine, but I couldn't find anything
> about the eZ80 in SDCC's project description or the mailing archive
> (last mention of it was in 2008).
>
> Thanks in advance.
>
>
> ------------------------------------------------------------------------------
> 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 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

[Sdcc-user] eZ80 support

[Bennett Ramirez <bennett.ramirez@gm...>]

Hello,

I'm wondering if the eZ80F91 is a supported target for SDCC. I am 
seeking a cross-platform alternative to ZDS, which is really geared 
toward development from a Windows machine, but I couldn't find anything 
about the eZ80 in SDCC's project description or the mailing archive 
(last mention of it was in 2008).

Thanks in advance.

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