Re: [Sdcc-user] Get the builtin macros list?

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

Am 13.06.2017 um 22:38 schrieb Miklos Marton:
> Hello all,
> 
> I am trying to use the SDCC's STM8 port with the QtCreator IDE with the
> QBS build system.
> 
> The QBS tries to get the predefined macros by running the compiler with
> "-Wp,-dM -E -x c /dev/null" arguments (in the case of gcc):
> 
> mm@...:~$ gcc -Wp,-dM -E -x c /dev/null
> #define __SSP_STRONG__ 3
> #define __DBL_MIN_EXP__ (-1021)
> #define __UINT_LEAST16_MAX__ 0xffff
> #define __ATOMIC_ACQUIRE 2
> #define __FLT_MIN__ 1.17549435082228750797e-38F
> #define __GCC_IEC_559_COMPLEX 2
> #define __UINT_LEAST8_TYPE__ unsigned char
> #define __SIZEOF_FLOAT80__ 16
> #define __INTMAX_C(c) c ## L
> #define __CHAR_BIT__ 8
> #define __UINT8_MAX__ 0xff
> 
> ....
> 
> Is there any similar argument list with the same could be queried in SDCC?
> 

I doesn't seem to work with /dev/null, but works with an empty test.c:

> sdcc -Wp,-dM -E test.c
#define __SDCC_mcs51 1
#define __STDC_VERSION__ 201112L
#define __STDC_HOSTED__ 0
#define __STDC_UTF_16__ 1
#define __SDCC_VERSION_MINOR 6
#define __SDCC_MODEL_SMALL 1
#define __STDC_ISO_10646__ 201409L
#define __SDCC_VERSION_PATCH 9
#define SDCC 369
#define __SDCC_FLOAT_REENT 1
#define __SDCC_VERSION_MAJOR 3
#define __STDC_NO_VLA__ 1
#define __SDCC 3_6_9
#define __STDC_UTF_32__ 1
#define __STDC_NO_THREADS__ 1
#define __SDCC_CHAR_UNSIGNED 1
#define __STDC_NO_ATOMICS__ 1
#define __STDC__ 1
#define __SDCC_REVISION 10096
#define __STDC_NO_COMPLEX__ 1

Philipp

Re: [Sdcc-user] problem with volatile struct member

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

Am 22.10.2017 um 20:26 schrieb Maarten Brock:
> Hello,
> 
>> Am 18.07.2017 um 16:59 schrieb Daniel Drotos:
>>>
>>> Hi,
>>>
>>> I'm using sdcc-stm8 with following code:
>>>
>>> struct FLASH_t { ... ; volatile uint8_t iapsr; ...};
>>> #define FLASH ((struct FLASH_t *)BASE_ADDRESS_OF_FLASH_CONTROLLER)
>>>
>>> Program waits end of flash operation in a busy loop:
>>>
>>> while ((FLASH->iapsr & 5) == 0) ...;
>>>
>>> it works well rereading value of iapsr in every check. But in following
>>> structure:
>>>
>>> uint8_t r= FLASH->iapsr;
>>> while ((r & 5) == 0)
>>>   r= FLASH->iapsr;
>>>
>>> iapsr is read just once and the cycle uses that value without rereading
>>> the register.
>>
>> As it should. FLASH->iapsr is read one, the result assinged to r. The
>> while only depends on r, not FLASH->iapsr
> 
> I don't think so. It should read FLASH->iapsr into r on every loop and
> reevaluate r.
> 
> Maarten
> 

Ah, sorry. Somehow I missed the assignment to r inside the loop. Anyway,
in that case this is most likely the same bug as #2673 that I just
opened, so this case will be fixed, too when #2673 gets fixed.

Philipp

Re: [Sdcc-user] problem with volatile struct member

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

Hello,

> Am 18.07.2017 um 16:59 schrieb Daniel Drotos:
>>
>> Hi,
>>
>> I'm using sdcc-stm8 with following code:
>>
>> struct FLASH_t { ... ; volatile uint8_t iapsr; ...};
>> #define FLASH ((struct FLASH_t *)BASE_ADDRESS_OF_FLASH_CONTROLLER)
>>
>> Program waits end of flash operation in a busy loop:
>>
>> while ((FLASH->iapsr & 5) == 0) ...;
>>
>> it works well rereading value of iapsr in every check. But in following
>> structure:
>>
>> uint8_t r= FLASH->iapsr;
>> while ((r & 5) == 0)
>>   r= FLASH->iapsr;
>>
>> iapsr is read just once and the cycle uses that value without rereading
>> the register.
>
> As it should. FLASH->iapsr is read one, the result assinged to r. The
> while only depends on r, not FLASH->iapsr

I don't think so. It should read FLASH->iapsr into r on every loop and
reevaluate r.

Maarten

Re: [Sdcc-user] problem with volatile struct member

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

Am 18.07.2017 um 16:59 schrieb Daniel Drotos:
> 
> Hi,
> 
> I'm using sdcc-stm8 with following code:
> 
> struct FLASH_t { ... ; volatile uint8_t iapsr; ...};
> #define FLASH ((struct FLASH_t *)BASE_ADDRESS_OF_FLASH_CONTROLLER)
> 
> Program waits end of flash operation in a busy loop:
> 
> while ((FLASH->iapsr & 5) == 0) ...;
> 
> it works well rereading value of iapsr in every check. But in following
> structure:
> 
> uint8_t r= FLASH->iapsr;
> while ((r & 5) == 0)
>   r= FLASH->iapsr;
> 
> iapsr is read just once and the cycle uses that value without rereading
> the register.

As it should. FLASH->iapsr is read one, the result assinged to r. The
while only depends on r, not FLASH->iapsr

> Even the following code uses the value which has been read
> before the cycle:
> 
> uint8_t r= FLASH->iapsr & 5;
> while ((FLASH->iapsr & 5) == 0) ...

This one is a bug. I'll file a bug erport.

Philipp

Re: [Sdcc-user] STM8L152C6 can not write to ADC registers

[Timo Fuckner <timo.fuckner@u-...>]

Wow, thank you all who looked into this. I'm sorry not having noticed this. What a big difference two switched letters can make. Writing and reading now works.

Thanks!
-Timo


-----Original Message-----
From: Philipp Klaus Krause [mailto:pkk@...] 
Sent: Donnerstag, 12. Oktober 2017 15:49
To: sdcc-user@...
Subject: Re: [Sdcc-user] STM8L152C6 can not write to ADC registers

I found the problem:

The clock to the ADC was off. It needs to be switched on using the correct PCKEN bit.
In the source posted, it looks as if the ADC clock got confused with the DAC clock: The comment indicates that the ADC clock is switched on where the DAC clock, but not the ADC clock is switched on.

Philipp

------------------------------------------------------------------------------
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] STM8L152C6 can not write to ADC registers

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

I found the problem:

The clock to the ADC was off. It needs to be switched on using the
correct PCKEN bit.
In the source posted, it looks as if the ADC clock got confused with the
DAC clock: The comment indicates that the ADC clock is switched on where
the DAC clock, but not the ADC clock is switched on.

Philipp

Re: [Sdcc-user] STM8L152C6 can not write to ADC registers

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

Am 12.10.2017 um 15:18 schrieb Philipp Klaus Krause:
> Am 12.10.2017 um 14:24 schrieb Timo Fuckner:
>> Ok so I just removed the unnecessary stuff and created a minimal example:
>>
>> https://pastebin.com/QPE14keu
>>
>> Writing a 0x01 in ADC1_CR1 results on 0x00 when read out.
>>
>> Regards,
>> Timo
> 
> I cna reproduce the issue using curretn SDCC on my STM8L-Discovery […]

But I don't see a problem in the generated asm.

Philipp

Re: [Sdcc-user] STM8L152C6 can not write to ADC registers

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

Am 12.10.2017 um 12:40 schrieb Timo Fuckner:
> Hello everyone,
> 
> I am currently having trouble writing the controlling registers for the ADC on STM8L152C6 (the discovery board [1]). Reading and writing the IO data and control registers works fine, but I can't change anything in the ADC registers as it seems, as they never change their RESET state. When reading them directly after setting them and directing the output to uart, there is no change. I'm not exactly sure if this is compiler or linker related, but to the best of my knowledge I did everything according to the handbook [2]. 
> 
> The affected registers are:
> ADC1_CR1
> ADC1_CR2
> ADC1_CR3
> ADC1_SQR1
> ADC1_SQR2
> ADC1_SQR3
> ADC1_SQR4
> 
> You can find my sourcecode here [3], SDCC version is 3.6, Win7. 
> The sdcc command is "sdcc -mstm8 --std-c99 usart.c". 
> For flashing I am using ST Visual Programmer 3.4.0.
> 
> I hope this is actually a bug in the compiler or linker and not a user error, so I won't waste your time.
> 
> Regards,
> Timo

Well, this code looks like you don't set ADON (lowest bit of ADC1_CR1)
to 1, while most ADC registers cannot be writtenwhile ADON is 0.

Philipp

Re: [Sdcc-user] STM8L152C6 can not write to ADC registers

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

Am 12.10.2017 um 14:24 schrieb Timo Fuckner:
> Ok so I just removed the unnecessary stuff and created a minimal example:
> 
> https://pastebin.com/QPE14keu
> 
> Writing a 0x01 in ADC1_CR1 results on 0x00 when read out.
> 
> Regards,
> Timo

I cna reproduce the issue using curretn SDCC on my STM8L-Discovery with
this code:

// Source code under CC0 1.0
#include <stdint.h>
#include <stdio.h>

#define PC_DDR	(*(volatile uint8_t *)0x500c)
#define PC_CR1	(*(volatile uint8_t *)0x500d)

#define EVER (;;)

//ADC Registers
#define ADC1_CR1        (*(volatile uint8_t *)0x5340)
#define ADC1_CR2        (*(volatile uint8_t *)0x5341)
#define ADC1_CR3        (*(volatile uint8_t *)0x5342)

//Clock
#define CLK_DIVR        (*(volatile uint8_t *)0x50C0)
#define CLK_PCKENR1     (*(volatile uint8_t *)0x50C3)
#define CLK_PCKENR2     (*(volatile uint8_t *)0x50C4)

//USART
#define USART1_SR       (*(volatile uint8_t *)0x5230)
#define USART1_DR       (*(volatile uint8_t *)0x5231)
#define USART1_BRR1     (*(volatile uint8_t *)0x5232)
#define USART1_BRR2     (*(volatile uint8_t *)0x5233)
#define USART1_CR2      (*(volatile uint8_t *)0x5235)
#define USART1_CR3      (*(volatile uint8_t *)0x5236)

#define USART_CR2_TEN   (1 << 3)
#define USART_CR3_STOP2 (1 << 5)
#define USART_CR3_STOP1 (1 << 4)
#define USART_SR_TXE    (1 << 7)

// we need to provide putchar, as it is controller specific
int putchar(int c)
{
    while(!(USART1_SR & USART_SR_TXE));

    USART1_DR = c;

    return(c);
}

void uart_init(void)
{
    PC_DDR = 0x08; // Put TX line on
    PC_CR1 = 0x08;

    USART1_CR2 = USART_CR2_TEN; // Allow TX and RX
    USART1_CR3 &= ~(USART_CR3_STOP1 | USART_CR3_STOP2); // 1 stop bit
    USART1_BRR2 = 0x03; USART1_BRR1 = 0x68; // 9600 baud
}

void main(void)
{
    unsigned long i = 0;

    CLK_DIVR = 0x00; // Set the frequency to 16 MHz
    CLK_PCKENR1 |= 0xFF; //(1 << 5) & (1 << 7); // Enable peripherals
UART & ADC

    uart_init();

    printf("Restarted...\r\n");

    for EVER
    {
        ADC1_CR1 = 0x01;
        printf("ADC1_CR1: %X\r\n", ADC1_CR1);
        for(i = 0; i < 0xFFFFF; i++); // Sleep
    }
}

Re: [Sdcc-user] STM8L152C6 can not write to ADC registers

[Vaclav Peroutka <vaclavpe@se...>]

Hello,

how does your ASM code look like ?

Vaclav

---------- Původní e-mail ----------
Od: Timo Fuckner <timo.fuckner@...>
Komu: sdcc-user@... <sdcc-user@...>
Datum: 12. 10. 2017 14:26:24
Předmět: Re: [Sdcc-user] STM8L152C6 can not write to ADC registers 
"Ok so I just removed the unnecessary stuff and created a minimal example: 

https://pastebin.com/QPE14keu 

Writing a 0x01 in ADC1_CR1 results on 0x00 when read out. 

Regards, 
Timo 

-----Original Message----- 
From: Timo Fuckner 
Sent: Donnerstag, 12. Oktober 2017 12:40 
To: sdcc-user@... 
Subject: [Sdcc-user] STM8L152C6 can not write to ADC registers 

Hello everyone, 

I am currently having trouble writing the controlling registers for the ADC 
on STM8L152C6 (the discovery board [1]). Reading and writing the IO data and
control registers works fine, but I can't change anything in the ADC 
registers as it seems, as they never change their RESET state. When reading 
them directly after setting them and directing the output to uart, there is 
no change. I'm not exactly sure if this is compiler or linker related, but 
to the best of my knowledge I did everything according to the handbook [2]. 


The affected registers are: 
ADC1_CR1 
ADC1_CR2 
ADC1_CR3 
ADC1_SQR1 
ADC1_SQR2 
ADC1_SQR3 
ADC1_SQR4 

You can find my sourcecode here [3], SDCC version is 3.6, Win7. 
The sdcc command is "sdcc -mstm8 --std-c99 usart.c". 
For flashing I am using ST Visual Programmer 3.4.0. 

I hope this is actually a bug in the compiler or linker and not a user 
error, so I won't waste your time. 

Regards, 
Timo 

[1] http://www.st.com/stm8l-discovery 
[2] http://www.st.com/content/ccc/resource/technical/document/reference_
manual/2e/3b/8c/8f/60/af/4b/2c/CD00218714.pdf/files/CD00218714.pdf/jcr:
content/translations/en.CD00218714.pdf 
[3] https://pastebin.com/sRSPSG58 



----------------------------------------------------------------------------
-- 
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] STM8L152C6 can not write to ADC registers

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

Am 12.10.2017 um 14:24 schrieb Timo Fuckner:
> Ok so I just removed the unnecessary stuff and created a minimal example:
> 
> https://pastebin.com/QPE14keu
> 
> Writing a 0x01 in ADC1_CR1 results on 0x00 when read out.
> 
> Regards,
> Timo

Could you also post the .asm and .lst files?

Philipp

Re: [Sdcc-user] STM8L152C6 can not write to ADC registers

[Timo Fuckner <timo.fuckner@u-...>]

Ok so I just removed the unnecessary stuff and created a minimal example:

https://pastebin.com/QPE14keu

Writing a 0x01 in ADC1_CR1 results on 0x00 when read out.

Regards,
Timo

-----Original Message-----
From: Timo Fuckner 
Sent: Donnerstag, 12. Oktober 2017 12:40
To: sdcc-user@...
Subject: [Sdcc-user] STM8L152C6 can not write to ADC registers

Hello everyone,

I am currently having trouble writing the controlling registers for the ADC on STM8L152C6 (the discovery board [1]). Reading and writing the IO data and control registers works fine, but I can't change anything in the ADC registers as it seems, as they never change their RESET state. When reading them directly after setting them and directing the output to uart, there is no change. I'm not exactly sure if this is compiler or linker related, but to the best of my knowledge I did everything according to the handbook [2]. 

The affected registers are:
ADC1_CR1
ADC1_CR2
ADC1_CR3
ADC1_SQR1
ADC1_SQR2
ADC1_SQR3
ADC1_SQR4

You can find my sourcecode here [3], SDCC version is 3.6, Win7. 
The sdcc command is "sdcc -mstm8 --std-c99 usart.c". 
For flashing I am using ST Visual Programmer 3.4.0.

I hope this is actually a bug in the compiler or linker and not a user error, so I won't waste your time.

Regards,
Timo

[1] http://www.st.com/stm8l-discovery
[2] http://www.st.com/content/ccc/resource/technical/document/reference_manual/2e/3b/8c/8f/60/af/4b/2c/CD00218714.pdf/files/CD00218714.pdf/jcr:content/translations/en.CD00218714.pdf
[3] https://pastebin.com/sRSPSG58



------------------------------------------------------------------------------
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] STM8L152C6 can not write to ADC registers

[Timo Fuckner <timo.fuckner@u-...>]

Hello everyone,

I am currently having trouble writing the controlling registers for the ADC on STM8L152C6 (the discovery board [1]). Reading and writing the IO data and control registers works fine, but I can't change anything in the ADC registers as it seems, as they never change their RESET state. When reading them directly after setting them and directing the output to uart, there is no change. I'm not exactly sure if this is compiler or linker related, but to the best of my knowledge I did everything according to the handbook [2]. 

The affected registers are:
ADC1_CR1
ADC1_CR2
ADC1_CR3
ADC1_SQR1
ADC1_SQR2
ADC1_SQR3
ADC1_SQR4

You can find my sourcecode here [3], SDCC version is 3.6, Win7. 
The sdcc command is "sdcc -mstm8 --std-c99 usart.c". 
For flashing I am using ST Visual Programmer 3.4.0.

I hope this is actually a bug in the compiler or linker and not a user error, so I won't waste your time.

Regards,
Timo

[1] http://www.st.com/stm8l-discovery
[2] http://www.st.com/content/ccc/resource/technical/document/reference_manual/2e/3b/8c/8f/60/af/4b/2c/CD00218714.pdf/files/CD00218714.pdf/jcr:content/translations/en.CD00218714.pdf
[3] https://pastebin.com/sRSPSG58

Re: [Sdcc-user] Sdcc-user] Killing z80 peephole rules

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

Am 03.10.2017 um 20:40 schrieb Alan Cox:
> On Mon, 2 Oct 2017 13:46:12 +0200
> Philipp Klaus Krause <pkk@...> wrote:
> 
>> Dear users of the z80 backend,
>>
>> I intend to remove some z80 peephole rules. […]
> 
> Fuzix uses 49g, 141a.

OK, I'll keep them.

> 49f and 49f' are I assumne different ?
> 

Yes.

Philipp

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

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

Am 14.05.2017 um 11:54 schrieb Maarten Brock:
> 
> 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

Thanks.
Do you have an example of how to set up the PLL for 98 Mhz on the
C8051F120? Based on the datasheet I've tried:

	OSCICN = 0xc3; // Run internal oscillator at full 24.5 Mhz

	// Set PLL to get SYSCLK to 98 Mhz
	FLSCL = 0xb0;
	PLL0CN = 0x01;
	PLL0FLT = 0x01;
	PLL0MUL = 0x04;
	for (unsigned char i = 0; i < 31; i++) // Wait 5 µs
        {
          __asm
          nop
          nop
          nop
          nop
          __endasm;
        }
	PLL0CN = 0x03;
	while (!(PLL0CN & 0x10));
	CLKSEL = 0x02;

but it doesn't seem to work for me.

Philipp

[Sdcc-user] Sdcc-user] Killing z80 peephole rules

[Alan Cox <alan@lx...>]

On Mon, 2 Oct 2017 13:46:12 +0200
Philipp Klaus Krause <pkk@...> wrote:

> Dear users of the z80 backend,
> 
> I intend to remove some z80 peephole rules. You might want to check if
> you are affected (by compiling your source usign current SDCC 3.6.9
> #10025 or later with --fverbose-asm, and checking the output, e.g. using
> a command like "grep peephole 21c test.asm".
> 
> While peephole rules are a quick way to get a bit of optimization, often
> improvements in code generation and register allocation can result in
> even better code (and also make old peephole rules obsolete).
> 
> None of these rules is currently used in the regression tests for z80.
> 
> Keeping unused and untested rules comes with a maintainance burden and a
> risk for bugs, so rules that are no longer used should be removed once
> in a while.
> 
> If one of the rules that I want to remove happens to be used by SDCC
> when compiling your code, please report on the list, and I well keep it.
> Ideally, you would also provide a small some compileable source example
> that SDCC uses the rule for.
> 
> Here is the list of rules to be removed:  

Fuzix uses 49g, 141a.

49f and 49f' are I assumne different ?

49g turns up in powf() in the C library severa times, and in soem device
drivers


141a turns up in driver code for the kernel in a few places (eg
sd_spi_init for socz80)

       ld      c, #0x14
;       genLabel
00131$:
;../dev/devsd_discard.c:93: sd_spi_receive_byte(); /* send dummy clocks
       -- at le ;       genCall
        push    bc
        call    _sd_spi_receive_byte
        pop     bc
;../dev/devsd_discard.c:92: for (n = 20; n; n--)
;       genMinus
;       genIfx
        dec c
; peephole 141a removed redundant transfer and flag setting in a
        jr      NZ,00131$

Re: [Sdcc-user] An experimental LLVM+SDCC-based toolchain for 8-bit microcontrollers

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

Am 03.10.2017 um 11:19 schrieb Georg Icking-Konert:
> hallo Philipp,
> 
>> To allow the use of langauges other than C and to evaluate the effect of
>> LLVM optimizations for 8-bit targets, I created an experimental
>> toolchain that allows the use of LLVM clang and opt with 8-bit
>> microcontrollers via the LLVm C backend and SDCC...
> 
> to my understanding the use of LLVM+SDCC would allow me to use C++ also
> for STM8. Is this understanding correct?

Yes.

> I recently played a bit with Arduino and got to appreciate that feature.
> Also I guess that the "STM8-Arduino" clone by tenbaht
> (https://github.com/tenbaht/sduino) could benefit from C++ support -->
> 
> May I ask what the current status of your LLVM+SDCC-toolchain is? Any
> plans to release it for dummies like me, i.e. download+extract+program?
> This would be highly appreciated!
> 
> Thanks a lot in advance and greetings from the Black Forest,
> Georg

I haven't worked on it recently. It is still experimental, based on old
LLVM 3.8 and the list of known issues at
http://www.colecovision.eu/llvm+sdcc/ is still up-todate.

The next steps would probably be:

1) Port cfe and cbe fork to current LLVM 4.0 or 5.0 (note that other cbe
forks have already been updated to LLVM 4.0, so it might be easy to port
the changes).
2) Fix the worst of the known issues.
3) Do more testing.
4) Fix more issues.

An easy-to-use release could maybe happen after that.

Philipp
(currently also in the Black Forest)

Re: [Sdcc-user] sdcc compile issues with vs2105

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

Am 03.10.2017 um 11:35 schrieb Raphael Neider:
> Hi,
> 
> On Oct 3, 2017 10:33, "Philipp Klaus Krause" <pkk@...
> <mailto:pkk@...>> wrote:
> 
>     Am 01.10.2017 um 23:40 schrieb alvin albrecht:
>     >
>     > I have a couple of compile issues using vs2015 with the current
>     version
>     > 10024.
>     >
>     > (1)
>     > In sdcc/src/SDCCralloc.hpp line 618, the compiler complains that there
>     > is an attempt to use deleted operator=.
>     > Line 591 gives the option to use alternative code and if I set the
>     IF to
>     > 0, the compile is fine.
>     >
>     > C:\Program Files (x86)\Microsoft Visual Studio
>     > 14.0\VC\include\xutility(458): error C2280:
>     > 'assignments_introduce_instruction::inserter_t
>     > &assignments_introduce_instruction::inserter_t::operator =(const
>     > assignments_introduce_instruction::inserter_t &)': attempting to
>     > reference a deleted function
>     >
>     > 2> C:\Projects\z80\z88dk\zsdcc\sdcc\src\SDCCralloc.hpp(618): note:
>     > compiler has generated
>     > 'assignments_introduce_instruction::inserter_t::operator =' here
>     >
>     > 2> C:\Program Files (x86)\Microsoft Visual Studio
>     > 14.0\VC\include\algorithm(3211): note: see reference to function
>     > template instantiation '_Iter &std::_Rechecked<_OutIt,_OutIt>(_Iter
>     > &,_UIter)' being compiled
> 
>     I don't think I know C++ well enough to really see what's going on here.
>     But it seems GCC 7 doesn't complain about that code, even when using
>     -pedantic --std=c++11 -Wall.
>     So maybe we just make the alternative code the default for Microsoft
>     Visual C++?
> 
> 
> To me this looks as if Microsoft generates the operator=(iterator_t
> &rhs) for our local struct as deleted, possibly because we do define
> some constructors and/or operator=() overloads. Manually providing an
> implementation of said (copy-)assignment operator - copying all fields
> from rhs to *this - might do the trick...
> The copy assignment operator is likely required for the (unused) return
> value of set_intersection().
> 
> Best regards,
> Raphael

I thought copy asignment opertators were only generated as deleted if
there is a user-declared move constructor. But the constructor that I
declared is not a move constructor.

For now (revision 10033) I just implemented the simple workaround of
replacing

#if 1

by

#if !defined(_MSC_VER)

Philipp

Re: [Sdcc-user] sdcc compile issues with vs2105

[Raphael Neider <rneider@we...>]

Hi,

On Oct 3, 2017 10:33, "Philipp Klaus Krause" <pkk@...> wrote:

Am 01.10.2017 um 23:40 schrieb alvin albrecht:
>
> I have a couple of compile issues using vs2015 with the current version
> 10024.
>
> (1)
> In sdcc/src/SDCCralloc.hpp line 618, the compiler complains that there
> is an attempt to use deleted operator=.
> Line 591 gives the option to use alternative code and if I set the IF to
> 0, the compile is fine.
>
> C:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\include\xutility(458): error C2280:
> 'assignments_introduce_instruction::inserter_t
> &assignments_introduce_instruction::inserter_t::operator =(const
> assignments_introduce_instruction::inserter_t &)': attempting to
> reference a deleted function
>
> 2> C:\Projects\z80\z88dk\zsdcc\sdcc\src\SDCCralloc.hpp(618): note:
> compiler has generated
> 'assignments_introduce_instruction::inserter_t::operator =' here
>
> 2> C:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\include\algorithm(3211): note: see reference to function
> template instantiation '_Iter &std::_Rechecked<_OutIt,_OutIt>(_Iter
> &,_UIter)' being compiled

I don't think I know C++ well enough to really see what's going on here.
But it seems GCC 7 doesn't complain about that code, even when using
-pedantic --std=c++11 -Wall.
So maybe we just make the alternative code the default for Microsoft
Visual C++?


To me this looks as if Microsoft generates the operator=(iterator_t &rhs)
for our local struct as deleted, possibly because we do define some
constructors and/or operator=() overloads. Manually providing an
implementation of said (copy-)assignment operator - copying all fields from
rhs to *this - might do the trick...
The copy assignment operator is likely required for the (unused) return
value of set_intersection().

Best regards,
Raphael

Re: [Sdcc-user] An experimental LLVM+SDCC-based toolchain for 8-bit microcontrollers

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

hallo Philipp,

> To allow the use of langauges other than C and to evaluate the effect of
> LLVM optimizations for 8-bit targets, I created an experimental
> toolchain that allows the use of LLVM clang and opt with 8-bit
> microcontrollers via the LLVm C backend and SDCC...

to my understanding the use of LLVM+SDCC would allow me to use C++ also 
for STM8. Is this understanding correct?

I recently played a bit with Arduino and got to appreciate that feature. 
Also I guess that the "STM8-Arduino" clone by tenbaht 
(https://github.com/tenbaht/sduino) could benefit from C++ support -->

May I ask what the current status of your LLVM+SDCC-toolchain is? Any 
plans to release it for dummies like me, i.e. download+extract+program? 
This would be highly appreciated!

Thanks a lot in advance and greetings from the Black Forest,
Georg

Re: [Sdcc-user] sdcc compile issues with vs2105

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

Am 01.10.2017 um 23:40 schrieb alvin albrecht:
> 
> I have a couple of compile issues using vs2015 with the current version
> 10024.
> 
> (1)
> In sdcc/src/SDCCralloc.hpp line 618, the compiler complains that there
> is an attempt to use deleted operator=.
> Line 591 gives the option to use alternative code and if I set the IF to
> 0, the compile is fine.
> 
> C:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\include\xutility(458): error C2280:
> 'assignments_introduce_instruction::inserter_t
> &assignments_introduce_instruction::inserter_t::operator =(const
> assignments_introduce_instruction::inserter_t &)': attempting to
> reference a deleted function
> 
> 2> C:\Projects\z80\z88dk\zsdcc\sdcc\src\SDCCralloc.hpp(618): note:
> compiler has generated
> 'assignments_introduce_instruction::inserter_t::operator =' here
> 
> 2> C:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\include\algorithm(3211): note: see reference to function
> template instantiation '_Iter &std::_Rechecked<_OutIt,_OutIt>(_Iter
> &,_UIter)' being compiled

I don't think I know C++ well enough to really see what's going on here.
But it seems GCC 7 doesn't complain about that code, even when using
-pedantic --std=c++11 -Wall.
So maybe we just make the alternative code the default for Microsoft
Visual C++?

> 
> 
> (2)
> In sdcc/src/hc08/ralloc2.cc the compile is warning […]

See this bug report:
https://sourceforge.net/p/sdcc/bugs/2215/

Philipp

[Sdcc-user] Killing hc08/s08 peephole rules

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

Dear users of the hc08 and s08 backends,

I intend to remove some hc08/s08 peephole rules.
For the why, and what you can do about it, see the post about the rules
for z80.

Here is the list of hc08/s08 rules to be removed:

4b
4d
7
10c
11a
11b

Philipp

[Sdcc-user] Killing r2k/r3k peephole rules

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

Dear users of the r2k and r3k backends,

I intend to remove some r2k/r3k peephole rules.
For the why, and what you can do about it, see the post about the rules
for z80.

Here is the list of r2k/e3k rules to be removed:

2
5
14
21
21a
21c
23
24
29
30
38
39
48
49
49e
49g
58
65b
65c
65d
66
71
73
74
81
83
84
85
91
92
93
93a
94
97
109a
109b
109c
110
111
111a
111b
111c
113
118
119
120
121
122
122a
123
124
126
128
129
130
131
132
133
134
135
136
138

Philipp

[Sdcc-user] Killing stm8 peephole rules

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

Dear users of the stm8 backend,

I intend to remove some stm8 peephole rules.
For the why, and what you can do about it, see the post about the rules
for z80.

Here is the list of stm8 rules to be removed:

0c
0e
3a
4
5
10
11-0
11-1
11-2
11-3
11-4
11-5
11-6
11-7
11-16
11-17
11-18
11-19
11-20
11-21
11-22
11-23
11-32
11-33
11-35
11-36
11-37
11-38
11-39
12-13
12-14

Philipp

[Sdcc-user] Killing z80 peephole rules

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

Dear users of the z80 backend,

I intend to remove some z80 peephole rules. You might want to check if
you are affected (by compiling your source usign current SDCC 3.6.9
#10025 or later with --fverbose-asm, and checking the output, e.g. using
a command like "grep peephole 21c test.asm".

While peephole rules are a quick way to get a bit of optimization, often
improvements in code generation and register allocation can result in
even better code (and also make old peephole rules obsolete).

None of these rules is currently used in the regression tests for z80.

Keeping unused and untested rules comes with a maintainance burden and a
risk for bugs, so rules that are no longer used should be removed once
in a while.

If one of the rules that I want to remove happens to be used by SDCC
when compiling your code, please report on the list, and I well keep it.
Ideally, you would also provide a small some compileable source example
that SDCC uses the rule for.

Here is the list of rules to be removed:

5
14
21
21a
21c
30
38
39
49f
49g
51b
51c
51d
51ethen
58
59
66
71
73
74
84
85
91
92
97
105
108
109
110
111a
111c
118
119If y
120
121
122
122a
123
126
128
129
130
131
132
140
141a
146

Philipp