[Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list
Hi!

There is an issue with globals initialization in matiec, when DT global variable is declared, the generated code id good, but it won't compile as accessor.h has erronious definition:

#define __INIT_GLOBAL(type, name, initial, retained)\
    {\
        static const type temp = initial;\
        __INIT_GLOBAL_##name(temp);\
        __INIT_RETAIN((*GLOBAL__##name), retained)\
    }

which accept only constant expression for "initial" argument!

So if we declare global DateVar : DT := DT#2017-12-01-01:23:34; then initial argument will be  __dt_to_timespec(34, 23, 1, 1, 12, 2017) which is obviously is not constant.

I propose the folowing definition:


#define __INIT_GLOBAL(type, name, initial, retained)\
    {\
        type temp = initial;\
        __INIT_GLOBAL_##name(temp);\
        __INIT_RETAIN((*GLOBAL__##name), retained)\
    }

Here is my test program:


PROGRAM Blink
  VAR
    Y0 : BOOL;
  END_VAR
  VAR_EXTERNAL
    LED0 : BOOL;
    LED1 : BOOL;
    MBReg0 : WORD;
    MenuPar1 : BOOL;
  END_VAR
  VAR
    RTC0 : RTC;
    PastDateTime : DT := DT#2017-12-01-01:23:34;
    CurrentDateTime : DT;
    BOOL_TO_WORD15_OUT : WORD;
  END_VAR

  Y0 := NOT(Y0);
  BOOL_TO_WORD15_OUT := BOOL_TO_WORD(Y0);
  MBReg0 := BOOL_TO_WORD15_OUT;
  LED0 := NOT(Y0);
  MenuPar1 := Y0;
  LED1 := Y0;
  RTC0(PDT := PastDateTime);
  CurrentDateTime := RTC0.CDT;
END_PROGRAM


CONFIGURATION config
  VAR_GLOBAL
    LED0 AT %QX4.0 : BOOL := True;
    LED1 AT %QX4.1 : BOOL := False;
    MBConf AT %QX2.1.9600.0 : BOOL := True;
    MBReg0 AT %MW2.0 : WORD := 0;
    MenuPar1 AT %MX4.1.3 : BOOL := 0;
    MenuPar2 AT %MX4.1.4 : BOOL := 0;
    DateVar : DT := DT#2017-12-01-01:23:34;
  END_VAR

  RESOURCE resource1 ON PLC
    TASK Timer_500ms(INTERVAL := T#500ms,PRIORITY := 0);
    PROGRAM Blink_Task WITH Timer_500ms : Blink;
  END_RESOURCE
END_CONFIGURATION


Best regards,
Paul Beltyukov

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list


 Good catch Paul!

 The static const was only there to try and save time (execution time) and
space (memory). Using static const would get the variable placed in the
initiliazed data segment, so it would not need to be initialized at runtime.

 This optimization is so tiny that I see no problem whatsoever in removing it.

 Does anybody see any issue with this proposed change?



  Cheers,

       Mario.




On Tuesday 09 May 2017 07:13:14 [hidden email] wrote:

> Hi!
>
> There is an issue with globals initialization in matiec, when DT global
> variable is declared, the generated code id good, but it won't compile as
> accessor.h has erronious definition:
>
> #define __INIT_GLOBAL(type, name, initial, retained)\
>
> >     {\
> >    
> >         static const type temp = initial;\
> >         __INIT_GLOBAL_##name(temp);\
> >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> >    
> >     }
>
> which accept only constant expression for "initial" argument!
>
> So if we declare global DateVar : DT := DT#2017-12-01-01:23:34; then
> initial argument will be  __dt_to_timespec(34, 23, 1, 1, 12, 2017) which is
> obviously is not constant.
>
> I propose the folowing definition:
> > #define __INIT_GLOBAL(type, name, initial, retained)\
> >
> >     {\
> >    
> >         type temp = initial;\
> >         __INIT_GLOBAL_##name(temp);\
> >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> >    
> >     }
>
> Here is my test program:
> > PROGRAM Blink
> >
> >   VAR
> >  
> >     Y0 : BOOL;
> >  
> >   END_VAR
> >   VAR_EXTERNAL
> >  
> >     LED0 : BOOL;
> >     LED1 : BOOL;
> >     MBReg0 : WORD;
> >     MenuPar1 : BOOL;
> >  
> >   END_VAR
> >   VAR
> >  
> >     RTC0 : RTC;
> >     PastDateTime : DT := DT#2017-12-01-01:23:34;
> >     CurrentDateTime : DT;
> >     BOOL_TO_WORD15_OUT : WORD;
> >  
> >   END_VAR
> >  
> >   Y0 := NOT(Y0);
> >   BOOL_TO_WORD15_OUT := BOOL_TO_WORD(Y0);
> >   MBReg0 := BOOL_TO_WORD15_OUT;
> >   LED0 := NOT(Y0);
> >   MenuPar1 := Y0;
> >   LED1 := Y0;
> >   RTC0(PDT := PastDateTime);
> >   CurrentDateTime := RTC0.CDT;
> >
> > END_PROGRAM
> >
> >
> > CONFIGURATION config
> >
> >   VAR_GLOBAL
> >  
> >     LED0 AT %QX4.0 : BOOL := True;
> >     LED1 AT %QX4.1 : BOOL := False;
> >     MBConf AT %QX2.1.9600.0 : BOOL := True;
> >     MBReg0 AT %MW2.0 : WORD := 0;
> >     MenuPar1 AT %MX4.1.3 : BOOL := 0;
> >     MenuPar2 AT %MX4.1.4 : BOOL := 0;
> >     DateVar : DT := DT#2017-12-01-01:23:34;
> >  
> >   END_VAR
> >  
> >   RESOURCE resource1 ON PLC
> >  
> >     TASK Timer_500ms(INTERVAL := T#500ms,PRIORITY := 0);
> >     PROGRAM Blink_Task WITH Timer_500ms : Blink;
> >  
> >   END_RESOURCE
> >
> > END_CONFIGURATION
>
> Best regards,
> Paul Beltyukov

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list
On 17-05-09 10:39, [hidden email] wrote:

>
>
>  Good catch Paul!
>
>  The static const was only there to try and save time (execution time) and
> space (memory). Using static const would get the variable placed in the
> initiliazed data segment, so it would not need to be initialized at runtime.
>
>  This optimization is so tiny that I see no problem whatsoever in removing it.
>
>  Does anybody see any issue with this proposed change?
Hi, Mario,
I think gcc will make this optimization anyway for constant values.

>
> On Tuesday 09 May 2017 07:13:14 [hidden email] wrote:
> > Hi!
> >
> > There is an issue with globals initialization in matiec, when DT global
> > variable is declared, the generated code id good, but it won't compile as
> > accessor.h has erronious definition:
> >
> > #define __INIT_GLOBAL(type, name, initial, retained)\
> >
> > >     {\
> > >    
> > >         static const type temp = initial;\
> > >         __INIT_GLOBAL_##name(temp);\
> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > >    
> > >     }
> >
> > which accept only constant expression for "initial" argument!
> >
> > So if we declare global DateVar : DT := DT#2017-12-01-01:23:34; then
> > initial argument will be  __dt_to_timespec(34, 23, 1, 1, 12, 2017) which is
> > obviously is not constant.
> >
> > I propose the folowing definition:
> > > #define __INIT_GLOBAL(type, name, initial, retained)\
> > >
> > >     {\
> > >    
> > >         type temp = initial;\
> > >         __INIT_GLOBAL_##name(temp);\
> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > >    
> > >     }
> >
> > Here is my test program:
> > > PROGRAM Blink
> > >
> > >   VAR
> > >  
> > >     Y0 : BOOL;
> > >  
> > >   END_VAR
> > >   VAR_EXTERNAL
> > >  
> > >     LED0 : BOOL;
> > >     LED1 : BOOL;
> > >     MBReg0 : WORD;
> > >     MenuPar1 : BOOL;
> > >  
> > >   END_VAR
> > >   VAR
> > >  
> > >     RTC0 : RTC;
> > >     PastDateTime : DT := DT#2017-12-01-01:23:34;
> > >     CurrentDateTime : DT;
> > >     BOOL_TO_WORD15_OUT : WORD;
> > >  
> > >   END_VAR
> > >  
> > >   Y0 := NOT(Y0);
> > >   BOOL_TO_WORD15_OUT := BOOL_TO_WORD(Y0);
> > >   MBReg0 := BOOL_TO_WORD15_OUT;
> > >   LED0 := NOT(Y0);
> > >   MenuPar1 := Y0;
> > >   LED1 := Y0;
> > >   RTC0(PDT := PastDateTime);
> > >   CurrentDateTime := RTC0.CDT;
> > >
> > > END_PROGRAM
> > >
> > >
> > > CONFIGURATION config
> > >
> > >   VAR_GLOBAL
> > >  
> > >     LED0 AT %QX4.0 : BOOL := True;
> > >     LED1 AT %QX4.1 : BOOL := False;
> > >     MBConf AT %QX2.1.9600.0 : BOOL := True;
> > >     MBReg0 AT %MW2.0 : WORD := 0;
> > >     MenuPar1 AT %MX4.1.3 : BOOL := 0;
> > >     MenuPar2 AT %MX4.1.4 : BOOL := 0;
> > >     DateVar : DT := DT#2017-12-01-01:23:34;
> > >  
> > >   END_VAR
> > >  
> > >   RESOURCE resource1 ON PLC
> > >  
> > >     TASK Timer_500ms(INTERVAL := T#500ms,PRIORITY := 0);
> > >     PROGRAM Blink_Task WITH Timer_500ms : Blink;
> > >  
> > >   END_RESOURCE
> > >
> > > END_CONFIGURATION
> >
> > Best regards,
> > Paul Beltyukov
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Beremiz-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/beremiz-devel
--
Best regards,
Andrey Skvortsov



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list


  I pushed Paul's bug fix to my repository.
  http://bitbucket.org/mjsousa/matiec

  Paul, do let me know if I messed up anything.


   Cheers,

          Mario




On 09.05.2017 10:49, [hidden email] wrote:

> On 17-05-09 10:39, [hidden email] wrote:
>>
>>
>>  Good catch Paul!
>>
>>  The static const was only there to try and save time (execution time)
>> and
>> space (memory). Using static const would get the variable placed in
>> the
>> initiliazed data segment, so it would not need to be initialized at
>> runtime.
>>
>>  This optimization is so tiny that I see no problem whatsoever in
>> removing it.
>>
>>  Does anybody see any issue with this proposed change?
>
> Hi, Mario,
> I think gcc will make this optimization anyway for constant values.
>
>>
>> On Tuesday 09 May 2017 07:13:14 [hidden email]
>> wrote:
>> > Hi!
>> >
>> > There is an issue with globals initialization in matiec, when DT global
>> > variable is declared, the generated code id good, but it won't compile as
>> > accessor.h has erronious definition:
>> >
>> > #define __INIT_GLOBAL(type, name, initial, retained)\
>> >
>> > >     {\
>> > >
>> > >         static const type temp = initial;\
>> > >         __INIT_GLOBAL_##name(temp);\
>> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
>> > >
>> > >     }
>> >
>> > which accept only constant expression for "initial" argument!
>> >
>> > So if we declare global DateVar : DT := DT#2017-12-01-01:23:34; then
>> > initial argument will be  __dt_to_timespec(34, 23, 1, 1, 12, 2017) which is
>> > obviously is not constant.
>> >
>> > I propose the folowing definition:
>> > > #define __INIT_GLOBAL(type, name, initial, retained)\
>> > >
>> > >     {\
>> > >
>> > >         type temp = initial;\
>> > >         __INIT_GLOBAL_##name(temp);\
>> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
>> > >
>> > >     }
>> >
>> > Here is my test program:
>> > > PROGRAM Blink
>> > >
>> > >   VAR
>> > >
>> > >     Y0 : BOOL;
>> > >
>> > >   END_VAR
>> > >   VAR_EXTERNAL
>> > >
>> > >     LED0 : BOOL;
>> > >     LED1 : BOOL;
>> > >     MBReg0 : WORD;
>> > >     MenuPar1 : BOOL;
>> > >
>> > >   END_VAR
>> > >   VAR
>> > >
>> > >     RTC0 : RTC;
>> > >     PastDateTime : DT := DT#2017-12-01-01:23:34;
>> > >     CurrentDateTime : DT;
>> > >     BOOL_TO_WORD15_OUT : WORD;
>> > >
>> > >   END_VAR
>> > >
>> > >   Y0 := NOT(Y0);
>> > >   BOOL_TO_WORD15_OUT := BOOL_TO_WORD(Y0);
>> > >   MBReg0 := BOOL_TO_WORD15_OUT;
>> > >   LED0 := NOT(Y0);
>> > >   MenuPar1 := Y0;
>> > >   LED1 := Y0;
>> > >   RTC0(PDT := PastDateTime);
>> > >   CurrentDateTime := RTC0.CDT;
>> > >
>> > > END_PROGRAM
>> > >
>> > >
>> > > CONFIGURATION config
>> > >
>> > >   VAR_GLOBAL
>> > >
>> > >     LED0 AT %QX4.0 : BOOL := True;
>> > >     LED1 AT %QX4.1 : BOOL := False;
>> > >     MBConf AT %QX2.1.9600.0 : BOOL := True;
>> > >     MBReg0 AT %MW2.0 : WORD := 0;
>> > >     MenuPar1 AT %MX4.1.3 : BOOL := 0;
>> > >     MenuPar2 AT %MX4.1.4 : BOOL := 0;
>> > >     DateVar : DT := DT#2017-12-01-01:23:34;
>> > >
>> > >   END_VAR
>> > >
>> > >   RESOURCE resource1 ON PLC
>> > >
>> > >     TASK Timer_500ms(INTERVAL := T#500ms,PRIORITY := 0);
>> > >     PROGRAM Blink_Task WITH Timer_500ms : Blink;
>> > >
>> > >   END_RESOURCE
>> > >
>> > > END_CONFIGURATION
>> >
>> > Best regards,
>> > Paul Beltyukov
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Beremiz-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/beremiz-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> _______________________________________________
> Beremiz-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/beremiz-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list
Hi!

Thank you, Mario! The only remaining question is:

What if "type" is some huge structure?

I think there may be a possibility of stack overflow...

What can other developers say on such hypothetical isssue?

Best regards,
Paul Beltyukov

2017-05-10 1:49 GMT+05:00 <[hidden email]>:


  I pushed Paul's bug fix to my repository.
  http://bitbucket.org/mjsousa/matiec

  Paul, do let me know if I messed up anything.


   Cheers,

          Mario




On 09.05.2017 10:49, [hidden email] wrote:
> On 17-05-09 10:39, [hidden email] wrote:
>>
>>
>>  Good catch Paul!
>>
>>  The static const was only there to try and save time (execution time)
>> and
>> space (memory). Using static const would get the variable placed in
>> the
>> initiliazed data segment, so it would not need to be initialized at
>> runtime.
>>
>>  This optimization is so tiny that I see no problem whatsoever in
>> removing it.
>>
>>  Does anybody see any issue with this proposed change?
>
> Hi, Mario,
> I think gcc will make this optimization anyway for constant values.
>
>>
>> On Tuesday 09 May 2017 07:13:14 [hidden email]
>> wrote:
>> > Hi!
>> >
>> > There is an issue with globals initialization in matiec, when DT global
>> > variable is declared, the generated code id good, but it won't compile as
>> > accessor.h has erronious definition:
>> >
>> > #define __INIT_GLOBAL(type, name, initial, retained)\
>> >
>> > >     {\
>> > >
>> > >         static const type temp = initial;\
>> > >         __INIT_GLOBAL_##name(temp);\
>> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
>> > >
>> > >     }
>> >
>> > which accept only constant expression for "initial" argument!
>> >
>> > So if we declare global DateVar : DT := DT#2017-12-01-01:23:34; then
>> > initial argument will be  __dt_to_timespec(34, 23, 1, 1, 12, 2017) which is
>> > obviously is not constant.
>> >
>> > I propose the folowing definition:
>> > > #define __INIT_GLOBAL(type, name, initial, retained)\
>> > >
>> > >     {\
>> > >
>> > >         type temp = initial;\
>> > >         __INIT_GLOBAL_##name(temp);\
>> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
>> > >
>> > >     }
>> >
>> > Here is my test program:
>> > > PROGRAM Blink
>> > >
>> > >   VAR
>> > >
>> > >     Y0 : BOOL;
>> > >
>> > >   END_VAR
>> > >   VAR_EXTERNAL
>> > >
>> > >     LED0 : BOOL;
>> > >     LED1 : BOOL;
>> > >     MBReg0 : WORD;
>> > >     MenuPar1 : BOOL;
>> > >
>> > >   END_VAR
>> > >   VAR
>> > >
>> > >     RTC0 : RTC;
>> > >     PastDateTime : DT := DT#2017-12-01-01:23:34;
>> > >     CurrentDateTime : DT;
>> > >     BOOL_TO_WORD15_OUT : WORD;
>> > >
>> > >   END_VAR
>> > >
>> > >   Y0 := NOT(Y0);
>> > >   BOOL_TO_WORD15_OUT := BOOL_TO_WORD(Y0);
>> > >   MBReg0 := BOOL_TO_WORD15_OUT;
>> > >   LED0 := NOT(Y0);
>> > >   MenuPar1 := Y0;
>> > >   LED1 := Y0;
>> > >   RTC0(PDT := PastDateTime);
>> > >   CurrentDateTime := RTC0.CDT;
>> > >
>> > > END_PROGRAM
>> > >
>> > >
>> > > CONFIGURATION config
>> > >
>> > >   VAR_GLOBAL
>> > >
>> > >     LED0 AT %QX4.0 : BOOL := True;
>> > >     LED1 AT %QX4.1 : BOOL := False;
>> > >     MBConf AT %QX2.1.9600.0 : BOOL := True;
>> > >     MBReg0 AT %MW2.0 : WORD := 0;
>> > >     MenuPar1 AT %MX4.1.3 : BOOL := 0;
>> > >     MenuPar2 AT %MX4.1.4 : BOOL := 0;
>> > >     DateVar : DT := DT#2017-12-01-01:23:34;
>> > >
>> > >   END_VAR
>> > >
>> > >   RESOURCE resource1 ON PLC
>> > >
>> > >     TASK Timer_500ms(INTERVAL := T#500ms,PRIORITY := 0);
>> > >     PROGRAM Blink_Task WITH Timer_500ms : Blink;
>> > >
>> > >   END_RESOURCE
>> > >
>> > > END_CONFIGURATION
>> >
>> > Best regards,
>> > Paul Beltyukov
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Beremiz-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/beremiz-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> _______________________________________________
> Beremiz-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/beremiz-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list
On 17-05-10 11:45, [hidden email] wrote:
> Hi!
>
> Thank you, Mario! The only remaining question is:
>
> What if "type" is some huge structure?
>
> I think there may be a possibility of stack overflow...
>
> What can other developers say on such hypothetical isssue?

I've done some investigations.
I wrote some simple example to test this hypothetical issue.
Flash addresses are like 0x80000000, RAM addresses are 0x20000000.

[------------------ main.c ------------------------]
struct a {
        int x;
        int y;
};

struct a var2;

void test_func(void)
{
        struct a var1 = { 1, 2 };
        var2 = var1;
}


int main(void)
{
        test_func();
        for(;;);
}
[---------------------------------------------------]

Compiled with arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.2.1 20151202 (release) [ARM/embedded-5-branch revision 231848]

using following command:
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -O2 -lc -lgcc -lnosys -Wl,-Map=output.map -o main.elf main.c


[----------- assembler listing ----------------------]
0800111c <test_func>:
 800111c:       4b02            ldr     r3, [pc, #8]    ; (8001128 <test_func+0xc>)
 800111e:       2201            movs    r2, #1
 8001120:       601a            str     r2, [r3, #0]
 8001122:       2202            movs    r2, #2
 8001124:       605a            str     r2, [r3, #4]
 8001126:       4770            bx      lr
 8001128:       2000045c        andcs   r0, r0, ip, asr r4
[---------------------------------------------------]

output.map doesn't contain any reference to var1.

See, no stack manipulation. var1 is optimized out and var2 is
initialized directly.

with -Os and -O1 results are similar. var1 is optimized out. You
probably already use one of these flags.



I tried the same with big structure (30 fields and total size 120
bytes). Here the picture is different. For big structures gcc starts
to use temporary variable on stack with any level of optimizations.

[----------- assembler listing ----------------------]
0800111c <test_func>:
 800111c:       b510            push    {r4, lr}
 800111e:       b09e            sub     sp, #120        ; 0x78
 8001120:       2478            movs    r4, #120        ; 0x78
 8001122:       4622            mov     r2, r4
 8001124:       4905            ldr     r1, [pc, #20]   ; (800113c <test_func+0x20>)
 8001126:       4668            mov     r0, sp
 8001128:       f000 f810       bl      800114c <memcpy>
 800112c:       4622            mov     r2, r4
 800112e:       4669            mov     r1, sp
 8001130:       4803            ldr     r0, [pc, #12]   ; (8001140 <test_func+0x24>)
 8001132:       f000 f80b       bl      800114c <memcpy>
 8001136:       b01e            add     sp, #120        ; 0x78
 8001138:       bd10            pop     {r4, pc}
 800113a:       bf00            nop
 800113c:       08001554        stmdaeq r0, {r2, r4, r6, r8, sl, ip}
 8001140:       2000045c        andcs   r0, r0, ip, asr r4
[---------------------------------------------------]

Actual problem with previous implementation was 'const', if I drop
'const', but leave 'static' in place, then all things are good again
with -O1, -O2, -O3, -Ofast, -Os and even with -Og.

[----------- assembler listing ----------------------]
0800111c <test_func>:
 800111c:       b508            push    {r3, lr}
 800111e:       2278            movs    r2, #120        ; 0x78
 8001120:       4902            ldr     r1, [pc, #8]    ; (800112c <test_func+0x10>)
 8001122:       4803            ldr     r0, [pc, #12]   ; (8001130 <test_func+0x14>)
 8001124:       f000 f80a       bl      800113c <memcpy>
 8001128:       bd08            pop     {r3, pc}
 800112a:       bf00            nop
 800112c:       08001544        stmdaeq r0, {r2, r6, r8, sl, ip}
 8001130:       2000045c        andcs   r0, r0, ip, asr r4
[---------------------------------------------------]

var1 is optimized, gcc uses memcpy and copies data from flash.
No stack, no temporary variables.

Unfortunately when no optimization level is selected (default is -O0), then
memory consumption is doubled because all these temporary variables
are static and are placed in .data section.

I'm not very happy with making temporary variable 'static', because
without optimizations it'll double memory consumption for big structures.
But I don't like stack overflows either on low-memory targets.

What do you think about that? Can we do better?

> Best regards,
> Paul Beltyukov
>
> 2017-05-10 1:49 GMT+05:00 <[hidden email]>:
>
> >
> >
> >   I pushed Paul's bug fix to my repository.
> >   http://bitbucket.org/mjsousa/matiec
> >
> >   Paul, do let me know if I messed up anything.
> >
> >
> >    Cheers,
> >
> >           Mario
> >
> >
> >
> >
> > On 09.05.2017 10:49, [hidden email] wrote:
> > > On 17-05-09 10:39, [hidden email] wrote:
> > >>
> > >>
> > >>  Good catch Paul!
> > >>
> > >>  The static const was only there to try and save time (execution time)
> > >> and
> > >> space (memory). Using static const would get the variable placed in
> > >> the
> > >> initiliazed data segment, so it would not need to be initialized at
> > >> runtime.
> > >>
> > >>  This optimization is so tiny that I see no problem whatsoever in
> > >> removing it.
> > >>
> > >>  Does anybody see any issue with this proposed change?
> > >
> > > Hi, Mario,
> > > I think gcc will make this optimization anyway for constant values.
> > >
> > >>
> > >> On Tuesday 09 May 2017 07:13:14 [hidden email]
> > >> wrote:
> > >> > Hi!
> > >> >
> > >> > There is an issue with globals initialization in matiec, when DT
> > global
> > >> > variable is declared, the generated code id good, but it won't
> > compile as
> > >> > accessor.h has erronious definition:
> > >> >
> > >> > #define __INIT_GLOBAL(type, name, initial, retained)\
> > >> >
> > >> > >     {\
> > >> > >
> > >> > >         static const type temp = initial;\
> > >> > >         __INIT_GLOBAL_##name(temp);\
> > >> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > >> > >
> > >> > >     }
> > >> >
> > >> > which accept only constant expression for "initial" argument!
> > >> >
> > >> > So if we declare global DateVar : DT := DT#2017-12-01-01:23:34; then
> > >> > initial argument will be  __dt_to_timespec(34, 23, 1, 1, 12, 2017)
> > which is
> > >> > obviously is not constant.
> > >> >
> > >> > I propose the folowing definition:
> > >> > > #define __INIT_GLOBAL(type, name, initial, retained)\
> > >> > >
> > >> > >     {\
> > >> > >
> > >> > >         type temp = initial;\
> > >> > >         __INIT_GLOBAL_##name(temp);\
> > >> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > >> > >
> > >> > >     }
> > >> >
> > >> > Here is my test program:
> > >> > > PROGRAM Blink
> > >> > >
> > >> > >   VAR
> > >> > >
> > >> > >     Y0 : BOOL;
> > >> > >
> > >> > >   END_VAR
> > >> > >   VAR_EXTERNAL
> > >> > >
> > >> > >     LED0 : BOOL;
> > >> > >     LED1 : BOOL;
> > >> > >     MBReg0 : WORD;
> > >> > >     MenuPar1 : BOOL;
> > >> > >
> > >> > >   END_VAR
> > >> > >   VAR
> > >> > >
> > >> > >     RTC0 : RTC;
> > >> > >     PastDateTime : DT := DT#2017-12-01-01:23:34;
> > >> > >     CurrentDateTime : DT;
> > >> > >     BOOL_TO_WORD15_OUT : WORD;
> > >> > >
> > >> > >   END_VAR
> > >> > >
> > >> > >   Y0 := NOT(Y0);
> > >> > >   BOOL_TO_WORD15_OUT := BOOL_TO_WORD(Y0);
> > >> > >   MBReg0 := BOOL_TO_WORD15_OUT;
> > >> > >   LED0 := NOT(Y0);
> > >> > >   MenuPar1 := Y0;
> > >> > >   LED1 := Y0;
> > >> > >   RTC0(PDT := PastDateTime);
> > >> > >   CurrentDateTime := RTC0.CDT;
> > >> > >
> > >> > > END_PROGRAM
> > >> > >
> > >> > >
> > >> > > CONFIGURATION config
> > >> > >
> > >> > >   VAR_GLOBAL
> > >> > >
> > >> > >     LED0 AT %QX4.0 : BOOL := True;
> > >> > >     LED1 AT %QX4.1 : BOOL := False;
> > >> > >     MBConf AT %QX2.1.9600.0 : BOOL := True;
> > >> > >     MBReg0 AT %MW2.0 : WORD := 0;
> > >> > >     MenuPar1 AT %MX4.1.3 : BOOL := 0;
> > >> > >     MenuPar2 AT %MX4.1.4 : BOOL := 0;
> > >> > >     DateVar : DT := DT#2017-12-01-01:23:34;
> > >> > >
> > >> > >   END_VAR
> > >> > >
> > >> > >   RESOURCE resource1 ON PLC
> > >> > >
> > >> > >     TASK Timer_500ms(INTERVAL := T#500ms,PRIORITY := 0);
> > >> > >     PROGRAM Blink_Task WITH Timer_500ms : Blink;
> > >> > >
> > >> > >   END_RESOURCE
> > >> > >
> > >> > > END_CONFIGURATION
> > >> >
> > >> > Best regards,
> > >> > Paul Beltyukov
> > >>
> > >> ------------------------------------------------------------
> > ------------------
> > >> Check out the vibrant tech community on one of the world's most
> > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > >> _______________________________________________
> > >> Beremiz-devel mailing list
> > >> [hidden email]
> > >> https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > >
> > > ------------------------------------------------------------
> > ------------------
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > >
> > > _______________________________________________
> > > Beremiz-devel mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> >
> >
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Beremiz-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> >

> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> _______________________________________________
> Beremiz-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/beremiz-devel


--
Best regards,
Andrey Skvortsov

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list
On 17-05-10 12:58, Andrey Skvortsov wrote:

> On 17-05-10 11:45, [hidden email] wrote:
> > Hi!
> >
> > Thank you, Mario! The only remaining question is:
> >
> > What if "type" is some huge structure?
> >
> > I think there may be a possibility of stack overflow...
> >
> > What can other developers say on such hypothetical isssue?
>
> I've done some investigations.
> I wrote some simple example to test this hypothetical issue.
> Flash addresses are like 0x80000000, RAM addresses are 0x20000000.
>
> [------------------ main.c ------------------------]
> struct a {
> int x;
> int y;
> };
>
> struct a var2;
>
> void test_func(void)
> {
> struct a var1 = { 1, 2 };
> var2 = var1;
> }
>
>
> int main(void)
> {
> test_func();
> for(;;);
> }
> [---------------------------------------------------]
>
> Compiled with arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.2.1 20151202 (release) [ARM/embedded-5-branch revision 231848]
>
> using following command:
> arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -O2 -lc -lgcc -lnosys -Wl,-Map=output.map -o main.elf main.c
>
>
> [----------- assembler listing ----------------------]
> 0800111c <test_func>:
>  800111c:       4b02            ldr     r3, [pc, #8]    ; (8001128 <test_func+0xc>)
>  800111e:       2201            movs    r2, #1
>  8001120:       601a            str     r2, [r3, #0]
>  8001122:       2202            movs    r2, #2
>  8001124:       605a            str     r2, [r3, #4]
>  8001126:       4770            bx      lr
>  8001128:       2000045c        andcs   r0, r0, ip, asr r4
> [---------------------------------------------------]
>
> output.map doesn't contain any reference to var1.
>
> See, no stack manipulation. var1 is optimized out and var2 is
> initialized directly.
>
> with -Os and -O1 results are similar. var1 is optimized out. You
> probably already use one of these flags.
>
>
>
> I tried the same with big structure (30 fields and total size 120
> bytes). Here the picture is different. For big structures gcc starts
> to use temporary variable on stack with any level of optimizations.
>
> [----------- assembler listing ----------------------]
> 0800111c <test_func>:
>  800111c:       b510            push    {r4, lr}
>  800111e:       b09e            sub     sp, #120        ; 0x78
>  8001120:       2478            movs    r4, #120        ; 0x78
>  8001122:       4622            mov     r2, r4
>  8001124:       4905            ldr     r1, [pc, #20]   ; (800113c <test_func+0x20>)
>  8001126:       4668            mov     r0, sp
>  8001128:       f000 f810       bl      800114c <memcpy>
>  800112c:       4622            mov     r2, r4
>  800112e:       4669            mov     r1, sp
>  8001130:       4803            ldr     r0, [pc, #12]   ; (8001140 <test_func+0x24>)
>  8001132:       f000 f80b       bl      800114c <memcpy>
>  8001136:       b01e            add     sp, #120        ; 0x78
>  8001138:       bd10            pop     {r4, pc}
>  800113a:       bf00            nop
>  800113c:       08001554        stmdaeq r0, {r2, r4, r6, r8, sl, ip}
>  8001140:       2000045c        andcs   r0, r0, ip, asr r4
> [---------------------------------------------------]
>
> Actual problem with previous implementation was 'const', if I drop
> 'const', but leave 'static' in place, then all things are good again
> with -O1, -O2, -O3, -Ofast, -Os and even with -Og.
>
> [----------- assembler listing ----------------------]
> 0800111c <test_func>:
>  800111c:       b508            push    {r3, lr}
>  800111e:       2278            movs    r2, #120        ; 0x78
>  8001120:       4902            ldr     r1, [pc, #8]    ; (800112c <test_func+0x10>)
>  8001122:       4803            ldr     r0, [pc, #12]   ; (8001130 <test_func+0x14>)
>  8001124:       f000 f80a       bl      800113c <memcpy>
>  8001128:       bd08            pop     {r3, pc}
>  800112a:       bf00            nop
>  800112c:       08001544        stmdaeq r0, {r2, r6, r8, sl, ip}
>  8001130:       2000045c        andcs   r0, r0, ip, asr r4
> [---------------------------------------------------]
>
> var1 is optimized, gcc uses memcpy and copies data from flash.
> No stack, no temporary variables.
>
> Unfortunately when no optimization level is selected (default is -O0), then
> memory consumption is doubled because all these temporary variables
> are static and are placed in .data section.
>
> I'm not very happy with making temporary variable 'static', because
> without optimizations it'll double memory consumption for big structures.
> But I don't like stack overflows either on low-memory targets.
>
> What do you think about that? Can we do better?
Targets, where all program and data should be in RAM (Windows, GNU/Linux)
'static const type temp = initial;'
and
'static type temp = initial;'

should have the same memory consumption. The difference is only
section name. All data will be anyway in RAM.

And developers for low-memory targets usually use all these fansy compiler
optimization, so in their case temporary variables will be optimized out.

--
Best regards,
Andrey Skvortsov

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
Hi, Andrey!

How about:

  #define __INIT_GLOBAL(type, name, initial, retained)\
    {\
        __INIT_VAL_ATTR##type type temp =  initial;\
        __INIT_GLOBAL_##name(temp);\
        __INIT_RETAIN((*GLOBAL__##name), retained)\
    } 
?

The main quecstion is how do we generate __INIT_VAL_ATTR##type, C-preprocessor doesn't have __define :(

Best regards,
Paul Beltyukov

2017-05-10 14:58 GMT+05:00 <[hidden email]>:
On 17-05-10 11:45, [hidden email] wrote:
> Hi!
>
> Thank you, Mario! The only remaining question is:
>
> What if "type" is some huge structure?
>
> I think there may be a possibility of stack overflow...
>
> What can other developers say on such hypothetical isssue?

I've done some investigations.
I wrote some simple example to test this hypothetical issue.
Flash addresses are like 0x80000000, RAM addresses are 0x20000000.

[------------------ main.c ------------------------]
struct a {
        int x;
        int y;
};

struct a var2;

void test_func(void)
{
        struct a var1 = { 1, 2 };
        var2 = var1;
}


int main(void)
{
        test_func();
        for(;;);
}
[---------------------------------------------------]

Compiled with arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.2.1 20151202 (release) [ARM/embedded-5-branch revision 231848]

using following command:
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -O2 -lc -lgcc -lnosys -Wl,-Map=output.map -o main.elf main.c


[----------- assembler listing ----------------------]
0800111c <test_func>:
 800111c:       4b02            ldr     r3, [pc, #8]    ; (8001128 <test_func+0xc>)
 800111e:       2201            movs    r2, #1
 8001120:       601a            str     r2, [r3, #0]
 8001122:       2202            movs    r2, #2
 8001124:       605a            str     r2, [r3, #4]
 8001126:       4770            bx      lr
 8001128:       2000045c        andcs   r0, r0, ip, asr r4
[---------------------------------------------------]

output.map doesn't contain any reference to var1.

See, no stack manipulation. var1 is optimized out and var2 is
initialized directly.

with -Os and -O1 results are similar. var1 is optimized out. You
probably already use one of these flags.



I tried the same with big structure (30 fields and total size 120
bytes). Here the picture is different. For big structures gcc starts
to use temporary variable on stack with any level of optimizations.

[----------- assembler listing ----------------------]
0800111c <test_func>:
 800111c:       b510            push    {r4, lr}
 800111e:       b09e            sub     sp, #120        ; 0x78
 8001120:       2478            movs    r4, #120        ; 0x78
 8001122:       4622            mov     r2, r4
 8001124:       4905            ldr     r1, [pc, #20]   ; (800113c <test_func+0x20>)
 8001126:       4668            mov     r0, sp
 8001128:       f000 f810       bl      800114c <memcpy>
 800112c:       4622            mov     r2, r4
 800112e:       4669            mov     r1, sp
 8001130:       4803            ldr     r0, [pc, #12]   ; (8001140 <test_func+0x24>)
 8001132:       f000 f80b       bl      800114c <memcpy>
 8001136:       b01e            add     sp, #120        ; 0x78
 8001138:       bd10            pop     {r4, pc}
 800113a:       bf00            nop
 800113c:       08001554        stmdaeq r0, {r2, r4, r6, r8, sl, ip}
 8001140:       2000045c        andcs   r0, r0, ip, asr r4
[---------------------------------------------------]

Actual problem with previous implementation was 'const', if I drop
'const', but leave 'static' in place, then all things are good again
with -O1, -O2, -O3, -Ofast, -Os and even with -Og.

[----------- assembler listing ----------------------]
0800111c <test_func>:
 800111c:       b508            push    {r3, lr}
 800111e:       2278            movs    r2, #120        ; 0x78
 8001120:       4902            ldr     r1, [pc, #8]    ; (800112c <test_func+0x10>)
 8001122:       4803            ldr     r0, [pc, #12]   ; (8001130 <test_func+0x14>)
 8001124:       f000 f80a       bl      800113c <memcpy>
 8001128:       bd08            pop     {r3, pc}
 800112a:       bf00            nop
 800112c:       08001544        stmdaeq r0, {r2, r6, r8, sl, ip}
 8001130:       2000045c        andcs   r0, r0, ip, asr r4
[---------------------------------------------------]

var1 is optimized, gcc uses memcpy and copies data from flash.
No stack, no temporary variables.

Unfortunately when no optimization level is selected (default is -O0), then
memory consumption is doubled because all these temporary variables
are static and are placed in .data section.

I'm not very happy with making temporary variable 'static', because
without optimizations it'll double memory consumption for big structures.
But I don't like stack overflows either on low-memory targets.

What do you think about that? Can we do better?

> Best regards,
> Paul Beltyukov
>
> 2017-05-10 1:49 GMT+05:00 <[hidden email]>:
>
> >
> >
> >   I pushed Paul's bug fix to my repository.
> >   http://bitbucket.org/mjsousa/matiec
> >
> >   Paul, do let me know if I messed up anything.
> >
> >
> >    Cheers,
> >
> >           Mario
> >
> >
> >
> >
> > On 09.05.2017 10:49, [hidden email] wrote:
> > > On 17-05-09 10:39, [hidden email] wrote:
> > >>
> > >>
> > >>  Good catch Paul!
> > >>
> > >>  The static const was only there to try and save time (execution time)
> > >> and
> > >> space (memory). Using static const would get the variable placed in
> > >> the
> > >> initiliazed data segment, so it would not need to be initialized at
> > >> runtime.
> > >>
> > >>  This optimization is so tiny that I see no problem whatsoever in
> > >> removing it.
> > >>
> > >>  Does anybody see any issue with this proposed change?
> > >
> > > Hi, Mario,
> > > I think gcc will make this optimization anyway for constant values.
> > >
> > >>
> > >> On Tuesday 09 May 2017 07:13:14 [hidden email]
> > >> wrote:
> > >> > Hi!
> > >> >
> > >> > There is an issue with globals initialization in matiec, when DT
> > global
> > >> > variable is declared, the generated code id good, but it won't
> > compile as
> > >> > accessor.h has erronious definition:
> > >> >
> > >> > #define __INIT_GLOBAL(type, name, initial, retained)\
> > >> >
> > >> > >     {\
> > >> > >
> > >> > >         static const type temp = initial;\
> > >> > >         __INIT_GLOBAL_##name(temp);\
> > >> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > >> > >
> > >> > >     }
> > >> >
> > >> > which accept only constant expression for "initial" argument!
> > >> >
> > >> > So if we declare global DateVar : DT := DT#2017-12-01-01:23:34; then
> > >> > initial argument will be  __dt_to_timespec(34, 23, 1, 1, 12, 2017)
> > which is
> > >> > obviously is not constant.
> > >> >
> > >> > I propose the folowing definition:
> > >> > > #define __INIT_GLOBAL(type, name, initial, retained)\
> > >> > >
> > >> > >     {\
> > >> > >
> > >> > >         type temp = initial;\
> > >> > >         __INIT_GLOBAL_##name(temp);\
> > >> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > >> > >
> > >> > >     }
> > >> >
> > >> > Here is my test program:
> > >> > > PROGRAM Blink
> > >> > >
> > >> > >   VAR
> > >> > >
> > >> > >     Y0 : BOOL;
> > >> > >
> > >> > >   END_VAR
> > >> > >   VAR_EXTERNAL
> > >> > >
> > >> > >     LED0 : BOOL;
> > >> > >     LED1 : BOOL;
> > >> > >     MBReg0 : WORD;
> > >> > >     MenuPar1 : BOOL;
> > >> > >
> > >> > >   END_VAR
> > >> > >   VAR
> > >> > >
> > >> > >     RTC0 : RTC;
> > >> > >     PastDateTime : DT := DT#2017-12-01-01:23:34;
> > >> > >     CurrentDateTime : DT;
> > >> > >     BOOL_TO_WORD15_OUT : WORD;
> > >> > >
> > >> > >   END_VAR
> > >> > >
> > >> > >   Y0 := NOT(Y0);
> > >> > >   BOOL_TO_WORD15_OUT := BOOL_TO_WORD(Y0);
> > >> > >   MBReg0 := BOOL_TO_WORD15_OUT;
> > >> > >   LED0 := NOT(Y0);
> > >> > >   MenuPar1 := Y0;
> > >> > >   LED1 := Y0;
> > >> > >   RTC0(PDT := PastDateTime);
> > >> > >   CurrentDateTime := RTC0.CDT;
> > >> > >
> > >> > > END_PROGRAM
> > >> > >
> > >> > >
> > >> > > CONFIGURATION config
> > >> > >
> > >> > >   VAR_GLOBAL
> > >> > >
> > >> > >     LED0 AT %QX4.0 : BOOL := True;
> > >> > >     LED1 AT %QX4.1 : BOOL := False;
> > >> > >     MBConf AT %QX2.1.9600.0 : BOOL := True;
> > >> > >     MBReg0 AT %MW2.0 : WORD := 0;
> > >> > >     MenuPar1 AT %MX4.1.3 : BOOL := 0;
> > >> > >     MenuPar2 AT %MX4.1.4 : BOOL := 0;
> > >> > >     DateVar : DT := DT#2017-12-01-01:23:34;
> > >> > >
> > >> > >   END_VAR
> > >> > >
> > >> > >   RESOURCE resource1 ON PLC
> > >> > >
> > >> > >     TASK Timer_500ms(INTERVAL := T#500ms,PRIORITY := 0);
> > >> > >     PROGRAM Blink_Task WITH Timer_500ms : Blink;
> > >> > >
> > >> > >   END_RESOURCE
> > >> > >
> > >> > > END_CONFIGURATION
> > >> >
> > >> > Best regards,
> > >> > Paul Beltyukov
> > >>
> > >> ------------------------------------------------------------
> > ------------------
> > >> Check out the vibrant tech community on one of the world's most
> > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > >> _______________________________________________
> > >> Beremiz-devel mailing list
> > >> [hidden email]
> > >> https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > >
> > > ------------------------------------------------------------
> > ------------------
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > >
> > > _______________________________________________
> > > Beremiz-devel mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> >
> >
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Beremiz-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> >

> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> _______________________________________________
> Beremiz-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/beremiz-devel


--
Best regards,
Andrey Skvortsov

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list
On 17-05-10 16:09, [hidden email] wrote:

> Hi, Andrey!
>
> How about:
>
>   #define __INIT_GLOBAL(type, name, initial, retained)\
> >     {\
> >         __INIT_VAL_ATTR##type type temp =  initial;\
> >         __INIT_GLOBAL_##name(temp);\
> >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> >     }
> >
> ?
>
> The main quecstion is how do we generate __INIT_VAL_ATTR##type,
> C-preprocessor doesn't have __define :(
What do you think about making local variable static as it was before
(but not const)?

static type temp = initial;



> Best regards,
> Paul Beltyukov
>
> 2017-05-10 14:58 GMT+05:00 <[hidden email]>:
>
> > On 17-05-10 11:45, [hidden email] wrote:
> > > Hi!
> > >
> > > Thank you, Mario! The only remaining question is:
> > >
> > > What if "type" is some huge structure?
> > >
> > > I think there may be a possibility of stack overflow...
> > >
> > > What can other developers say on such hypothetical isssue?
> >
> > I've done some investigations.
> > I wrote some simple example to test this hypothetical issue.
> > Flash addresses are like 0x80000000, RAM addresses are 0x20000000.
> >
> > [------------------ main.c ------------------------]
> > struct a {
> >         int x;
> >         int y;
> > };
> >
> > struct a var2;
> >
> > void test_func(void)
> > {
> >         struct a var1 = { 1, 2 };
> >         var2 = var1;
> > }
> >
> >
> > int main(void)
> > {
> >         test_func();
> >         for(;;);
> > }
> > [---------------------------------------------------]
> >
> > Compiled with arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors)
> > 5.2.1 20151202 (release) [ARM/embedded-5-branch revision 231848]
> >
> > using following command:
> > arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -O2 -lc -lgcc -lnosys
> > -Wl,-Map=output.map -o main.elf main.c
> >
> >
> > [----------- assembler listing ----------------------]
> > 0800111c <test_func>:
> >  800111c:       4b02            ldr     r3, [pc, #8]    ; (8001128
> > <test_func+0xc>)
> >  800111e:       2201            movs    r2, #1
> >  8001120:       601a            str     r2, [r3, #0]
> >  8001122:       2202            movs    r2, #2
> >  8001124:       605a            str     r2, [r3, #4]
> >  8001126:       4770            bx      lr
> >  8001128:       2000045c        andcs   r0, r0, ip, asr r4
> > [---------------------------------------------------]
> >
> > output.map doesn't contain any reference to var1.
> >
> > See, no stack manipulation. var1 is optimized out and var2 is
> > initialized directly.
> >
> > with -Os and -O1 results are similar. var1 is optimized out. You
> > probably already use one of these flags.
> >
> >
> >
> > I tried the same with big structure (30 fields and total size 120
> > bytes). Here the picture is different. For big structures gcc starts
> > to use temporary variable on stack with any level of optimizations.
> >
> > [----------- assembler listing ----------------------]
> > 0800111c <test_func>:
> >  800111c:       b510            push    {r4, lr}
> >  800111e:       b09e            sub     sp, #120        ; 0x78
> >  8001120:       2478            movs    r4, #120        ; 0x78
> >  8001122:       4622            mov     r2, r4
> >  8001124:       4905            ldr     r1, [pc, #20]   ; (800113c
> > <test_func+0x20>)
> >  8001126:       4668            mov     r0, sp
> >  8001128:       f000 f810       bl      800114c <memcpy>
> >  800112c:       4622            mov     r2, r4
> >  800112e:       4669            mov     r1, sp
> >  8001130:       4803            ldr     r0, [pc, #12]   ; (8001140
> > <test_func+0x24>)
> >  8001132:       f000 f80b       bl      800114c <memcpy>
> >  8001136:       b01e            add     sp, #120        ; 0x78
> >  8001138:       bd10            pop     {r4, pc}
> >  800113a:       bf00            nop
> >  800113c:       08001554        stmdaeq r0, {r2, r4, r6, r8, sl, ip}
> >  8001140:       2000045c        andcs   r0, r0, ip, asr r4
> > [---------------------------------------------------]
> >
> > Actual problem with previous implementation was 'const', if I drop
> > 'const', but leave 'static' in place, then all things are good again
> > with -O1, -O2, -O3, -Ofast, -Os and even with -Og.
> >
> > [----------- assembler listing ----------------------]
> > 0800111c <test_func>:
> >  800111c:       b508            push    {r3, lr}
> >  800111e:       2278            movs    r2, #120        ; 0x78
> >  8001120:       4902            ldr     r1, [pc, #8]    ; (800112c
> > <test_func+0x10>)
> >  8001122:       4803            ldr     r0, [pc, #12]   ; (8001130
> > <test_func+0x14>)
> >  8001124:       f000 f80a       bl      800113c <memcpy>
> >  8001128:       bd08            pop     {r3, pc}
> >  800112a:       bf00            nop
> >  800112c:       08001544        stmdaeq r0, {r2, r6, r8, sl, ip}
> >  8001130:       2000045c        andcs   r0, r0, ip, asr r4
> > [---------------------------------------------------]
> >
> > var1 is optimized, gcc uses memcpy and copies data from flash.
> > No stack, no temporary variables.
> >
> > Unfortunately when no optimization level is selected (default is -O0), then
> > memory consumption is doubled because all these temporary variables
> > are static and are placed in .data section.
> >
> > I'm not very happy with making temporary variable 'static', because
> > without optimizations it'll double memory consumption for big structures.
> > But I don't like stack overflows either on low-memory targets.
> >
> > What do you think about that? Can we do better?
> >
> > > Best regards,
> > > Paul Beltyukov
> > >
> > > 2017-05-10 1:49 GMT+05:00 <[hidden email]>:
> > >
> > > >
> > > >
> > > >   I pushed Paul's bug fix to my repository.
> > > >   http://bitbucket.org/mjsousa/matiec
> > > >
> > > >   Paul, do let me know if I messed up anything.
> > > >
> > > >
> > > >    Cheers,
> > > >
> > > >           Mario
> > > >
> > > >
> > > >
> > > >
> > > > On 09.05.2017 10:49, [hidden email] wrote:
> > > > > On 17-05-09 10:39, [hidden email] wrote:
> > > > >>
> > > > >>
> > > > >>  Good catch Paul!
> > > > >>
> > > > >>  The static const was only there to try and save time (execution
> > time)
> > > > >> and
> > > > >> space (memory). Using static const would get the variable placed in
> > > > >> the
> > > > >> initiliazed data segment, so it would not need to be initialized at
> > > > >> runtime.
> > > > >>
> > > > >>  This optimization is so tiny that I see no problem whatsoever in
> > > > >> removing it.
> > > > >>
> > > > >>  Does anybody see any issue with this proposed change?
> > > > >
> > > > > Hi, Mario,
> > > > > I think gcc will make this optimization anyway for constant values.
> > > > >
> > > > >>
> > > > >> On Tuesday 09 May 2017 07:13:14 [hidden email]
> > > > >> wrote:
> > > > >> > Hi!
> > > > >> >
> > > > >> > There is an issue with globals initialization in matiec, when DT
> > > > global
> > > > >> > variable is declared, the generated code id good, but it won't
> > > > compile as
> > > > >> > accessor.h has erronious definition:
> > > > >> >
> > > > >> > #define __INIT_GLOBAL(type, name, initial, retained)\
> > > > >> >
> > > > >> > >     {\
> > > > >> > >
> > > > >> > >         static const type temp = initial;\
> > > > >> > >         __INIT_GLOBAL_##name(temp);\
> > > > >> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > > > >> > >
> > > > >> > >     }
> > > > >> >
> > > > >> > which accept only constant expression for "initial" argument!
> > > > >> >
> > > > >> > So if we declare global DateVar : DT := DT#2017-12-01-01:23:34;
> > then
> > > > >> > initial argument will be  __dt_to_timespec(34, 23, 1, 1, 12, 2017)
> > > > which is
> > > > >> > obviously is not constant.
> > > > >> >
> > > > >> > I propose the folowing definition:
> > > > >> > > #define __INIT_GLOBAL(type, name, initial, retained)\
> > > > >> > >
> > > > >> > >     {\
> > > > >> > >
> > > > >> > >         type temp = initial;\
> > > > >> > >         __INIT_GLOBAL_##name(temp);\
> > > > >> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > > > >> > >
> > > > >> > >     }
> > > > >> >
> > > > >> > Here is my test program:
> > > > >> > > PROGRAM Blink
> > > > >> > >
> > > > >> > >   VAR
> > > > >> > >
> > > > >> > >     Y0 : BOOL;
> > > > >> > >
> > > > >> > >   END_VAR
> > > > >> > >   VAR_EXTERNAL
> > > > >> > >
> > > > >> > >     LED0 : BOOL;
> > > > >> > >     LED1 : BOOL;
> > > > >> > >     MBReg0 : WORD;
> > > > >> > >     MenuPar1 : BOOL;
> > > > >> > >
> > > > >> > >   END_VAR
> > > > >> > >   VAR
> > > > >> > >
> > > > >> > >     RTC0 : RTC;
> > > > >> > >     PastDateTime : DT := DT#2017-12-01-01:23:34;
> > > > >> > >     CurrentDateTime : DT;
> > > > >> > >     BOOL_TO_WORD15_OUT : WORD;
> > > > >> > >
> > > > >> > >   END_VAR
> > > > >> > >
> > > > >> > >   Y0 := NOT(Y0);
> > > > >> > >   BOOL_TO_WORD15_OUT := BOOL_TO_WORD(Y0);
> > > > >> > >   MBReg0 := BOOL_TO_WORD15_OUT;
> > > > >> > >   LED0 := NOT(Y0);
> > > > >> > >   MenuPar1 := Y0;
> > > > >> > >   LED1 := Y0;
> > > > >> > >   RTC0(PDT := PastDateTime);
> > > > >> > >   CurrentDateTime := RTC0.CDT;
> > > > >> > >
> > > > >> > > END_PROGRAM
> > > > >> > >
> > > > >> > >
> > > > >> > > CONFIGURATION config
> > > > >> > >
> > > > >> > >   VAR_GLOBAL
> > > > >> > >
> > > > >> > >     LED0 AT %QX4.0 : BOOL := True;
> > > > >> > >     LED1 AT %QX4.1 : BOOL := False;
> > > > >> > >     MBConf AT %QX2.1.9600.0 : BOOL := True;
> > > > >> > >     MBReg0 AT %MW2.0 : WORD := 0;
> > > > >> > >     MenuPar1 AT %MX4.1.3 : BOOL := 0;
> > > > >> > >     MenuPar2 AT %MX4.1.4 : BOOL := 0;
> > > > >> > >     DateVar : DT := DT#2017-12-01-01:23:34;
> > > > >> > >
> > > > >> > >   END_VAR
> > > > >> > >
> > > > >> > >   RESOURCE resource1 ON PLC
> > > > >> > >
> > > > >> > >     TASK Timer_500ms(INTERVAL := T#500ms,PRIORITY := 0);
> > > > >> > >     PROGRAM Blink_Task WITH Timer_500ms : Blink;
> > > > >> > >
> > > > >> > >   END_RESOURCE
> > > > >> > >
> > > > >> > > END_CONFIGURATION
> > > > >> >
> > > > >> > Best regards,
> > > > >> > Paul Beltyukov
> > > > >>
> > > > >> ------------------------------------------------------------
> > > > ------------------
> > > > >> Check out the vibrant tech community on one of the world's most
> > > > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > >> _______________________________________________
> > > > >> Beremiz-devel mailing list
> > > > >> [hidden email]
> > > > >> https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > > > >
> > > > > ------------------------------------------------------------
> > > > ------------------
> > > > > Check out the vibrant tech community on one of the world's most
> > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > >
> > > > > _______________________________________________
> > > > > Beremiz-devel mailing list
> > > > > [hidden email]
> > > > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > > >
> > > >
> > > > ------------------------------------------------------------
> > > > ------------------
> > > > Check out the vibrant tech community on one of the world's most
> > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > _______________________________________________
> > > > Beremiz-devel mailing list
> > > > [hidden email]
> > > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > > >
> >
> > > ------------------------------------------------------------
> > ------------------
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> > > _______________________________________________
> > > Beremiz-devel mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> >
> >
> > --
> > Best regards,
> > Andrey Skvortsov
> >
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Beremiz-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> >
> >

> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> _______________________________________________
> Beremiz-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/beremiz-devel


--
Best regards,
Andrey Skvortsov

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list
Well, I consider it static initializer more evil: stack is "dynamic", so we can use "one storage" for all initializers,
in case of static var the memory usage will be [bold]LARGER[/bold], so we get memory space overflow earlier.

Best regards,
Paul Beltyukov

2017-05-10 16:16 GMT+05:00 <[hidden email]>:
On 17-05-10 16:09, [hidden email] wrote:
> Hi, Andrey!
>
> How about:
>
>   #define __INIT_GLOBAL(type, name, initial, retained)\
> >     {\
> >         __INIT_VAL_ATTR##type type temp =  initial;\
> >         __INIT_GLOBAL_##name(temp);\
> >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> >     }
> >
> ?
>
> The main quecstion is how do we generate __INIT_VAL_ATTR##type,
> C-preprocessor doesn't have __define :(

What do you think about making local variable static as it was before
(but not const)?

static type temp = initial;



> Best regards,
> Paul Beltyukov
>
> 2017-05-10 14:58 GMT+05:00 <[hidden email]>:
>
> > On 17-05-10 11:45, [hidden email] wrote:
> > > Hi!
> > >
> > > Thank you, Mario! The only remaining question is:
> > >
> > > What if "type" is some huge structure?
> > >
> > > I think there may be a possibility of stack overflow...
> > >
> > > What can other developers say on such hypothetical isssue?
> >
> > I've done some investigations.
> > I wrote some simple example to test this hypothetical issue.
> > Flash addresses are like 0x80000000, RAM addresses are 0x20000000.
> >
> > [------------------ main.c ------------------------]
> > struct a {
> >         int x;
> >         int y;
> > };
> >
> > struct a var2;
> >
> > void test_func(void)
> > {
> >         struct a var1 = { 1, 2 };
> >         var2 = var1;
> > }
> >
> >
> > int main(void)
> > {
> >         test_func();
> >         for(;;);
> > }
> > [---------------------------------------------------]
> >
> > Compiled with arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors)
> > 5.2.1 20151202 (release) [ARM/embedded-5-branch revision 231848]
> >
> > using following command:
> > arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -O2 -lc -lgcc -lnosys
> > -Wl,-Map=output.map -o main.elf main.c
> >
> >
> > [----------- assembler listing ----------------------]
> > 0800111c <test_func>:
> >  800111c:       4b02            ldr     r3, [pc, #8]    ; (8001128
> > <test_func+0xc>)
> >  800111e:       2201            movs    r2, #1
> >  8001120:       601a            str     r2, [r3, #0]
> >  8001122:       2202            movs    r2, #2
> >  8001124:       605a            str     r2, [r3, #4]
> >  8001126:       4770            bx      lr
> >  8001128:       2000045c        andcs   r0, r0, ip, asr r4
> > [---------------------------------------------------]
> >
> > output.map doesn't contain any reference to var1.
> >
> > See, no stack manipulation. var1 is optimized out and var2 is
> > initialized directly.
> >
> > with -Os and -O1 results are similar. var1 is optimized out. You
> > probably already use one of these flags.
> >
> >
> >
> > I tried the same with big structure (30 fields and total size 120
> > bytes). Here the picture is different. For big structures gcc starts
> > to use temporary variable on stack with any level of optimizations.
> >
> > [----------- assembler listing ----------------------]
> > 0800111c <test_func>:
> >  800111c:       b510            push    {r4, lr}
> >  800111e:       b09e            sub     sp, #120        ; 0x78
> >  8001120:       2478            movs    r4, #120        ; 0x78
> >  8001122:       4622            mov     r2, r4
> >  8001124:       4905            ldr     r1, [pc, #20]   ; (800113c
> > <test_func+0x20>)
> >  8001126:       4668            mov     r0, sp
> >  8001128:       f000 f810       bl      800114c <memcpy>
> >  800112c:       4622            mov     r2, r4
> >  800112e:       4669            mov     r1, sp
> >  8001130:       4803            ldr     r0, [pc, #12]   ; (8001140
> > <test_func+0x24>)
> >  8001132:       f000 f80b       bl      800114c <memcpy>
> >  8001136:       b01e            add     sp, #120        ; 0x78
> >  8001138:       bd10            pop     {r4, pc}
> >  800113a:       bf00            nop
> >  800113c:       08001554        stmdaeq r0, {r2, r4, r6, r8, sl, ip}
> >  8001140:       2000045c        andcs   r0, r0, ip, asr r4
> > [---------------------------------------------------]
> >
> > Actual problem with previous implementation was 'const', if I drop
> > 'const', but leave 'static' in place, then all things are good again
> > with -O1, -O2, -O3, -Ofast, -Os and even with -Og.
> >
> > [----------- assembler listing ----------------------]
> > 0800111c <test_func>:
> >  800111c:       b508            push    {r3, lr}
> >  800111e:       2278            movs    r2, #120        ; 0x78
> >  8001120:       4902            ldr     r1, [pc, #8]    ; (800112c
> > <test_func+0x10>)
> >  8001122:       4803            ldr     r0, [pc, #12]   ; (8001130
> > <test_func+0x14>)
> >  8001124:       f000 f80a       bl      800113c <memcpy>
> >  8001128:       bd08            pop     {r3, pc}
> >  800112a:       bf00            nop
> >  800112c:       08001544        stmdaeq r0, {r2, r6, r8, sl, ip}
> >  8001130:       2000045c        andcs   r0, r0, ip, asr r4
> > [---------------------------------------------------]
> >
> > var1 is optimized, gcc uses memcpy and copies data from flash.
> > No stack, no temporary variables.
> >
> > Unfortunately when no optimization level is selected (default is -O0), then
> > memory consumption is doubled because all these temporary variables
> > are static and are placed in .data section.
> >
> > I'm not very happy with making temporary variable 'static', because
> > without optimizations it'll double memory consumption for big structures.
> > But I don't like stack overflows either on low-memory targets.
> >
> > What do you think about that? Can we do better?
> >
> > > Best regards,
> > > Paul Beltyukov
> > >
> > > 2017-05-10 1:49 GMT+05:00 <[hidden email]>:
> > >
> > > >
> > > >
> > > >   I pushed Paul's bug fix to my repository.
> > > >   http://bitbucket.org/mjsousa/matiec
> > > >
> > > >   Paul, do let me know if I messed up anything.
> > > >
> > > >
> > > >    Cheers,
> > > >
> > > >           Mario
> > > >
> > > >
> > > >
> > > >
> > > > On 09.05.2017 10:49, [hidden email] wrote:
> > > > > On 17-05-09 10:39, [hidden email] wrote:
> > > > >>
> > > > >>
> > > > >>  Good catch Paul!
> > > > >>
> > > > >>  The static const was only there to try and save time (execution
> > time)
> > > > >> and
> > > > >> space (memory). Using static const would get the variable placed in
> > > > >> the
> > > > >> initiliazed data segment, so it would not need to be initialized at
> > > > >> runtime.
> > > > >>
> > > > >>  This optimization is so tiny that I see no problem whatsoever in
> > > > >> removing it.
> > > > >>
> > > > >>  Does anybody see any issue with this proposed change?
> > > > >
> > > > > Hi, Mario,
> > > > > I think gcc will make this optimization anyway for constant values.
> > > > >
> > > > >>
> > > > >> On Tuesday 09 May 2017 07:13:14 [hidden email]
> > > > >> wrote:
> > > > >> > Hi!
> > > > >> >
> > > > >> > There is an issue with globals initialization in matiec, when DT
> > > > global
> > > > >> > variable is declared, the generated code id good, but it won't
> > > > compile as
> > > > >> > accessor.h has erronious definition:
> > > > >> >
> > > > >> > #define __INIT_GLOBAL(type, name, initial, retained)\
> > > > >> >
> > > > >> > >     {\
> > > > >> > >
> > > > >> > >         static const type temp = initial;\
> > > > >> > >         __INIT_GLOBAL_##name(temp);\
> > > > >> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > > > >> > >
> > > > >> > >     }
> > > > >> >
> > > > >> > which accept only constant expression for "initial" argument!
> > > > >> >
> > > > >> > So if we declare global DateVar : DT := DT#2017-12-01-01:23:34;
> > then
> > > > >> > initial argument will be  __dt_to_timespec(34, 23, 1, 1, 12, 2017)
> > > > which is
> > > > >> > obviously is not constant.
> > > > >> >
> > > > >> > I propose the folowing definition:
> > > > >> > > #define __INIT_GLOBAL(type, name, initial, retained)\
> > > > >> > >
> > > > >> > >     {\
> > > > >> > >
> > > > >> > >         type temp = initial;\
> > > > >> > >         __INIT_GLOBAL_##name(temp);\
> > > > >> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > > > >> > >
> > > > >> > >     }
> > > > >> >
> > > > >> > Here is my test program:
> > > > >> > > PROGRAM Blink
> > > > >> > >
> > > > >> > >   VAR
> > > > >> > >
> > > > >> > >     Y0 : BOOL;
> > > > >> > >
> > > > >> > >   END_VAR
> > > > >> > >   VAR_EXTERNAL
> > > > >> > >
> > > > >> > >     LED0 : BOOL;
> > > > >> > >     LED1 : BOOL;
> > > > >> > >     MBReg0 : WORD;
> > > > >> > >     MenuPar1 : BOOL;
> > > > >> > >
> > > > >> > >   END_VAR
> > > > >> > >   VAR
> > > > >> > >
> > > > >> > >     RTC0 : RTC;
> > > > >> > >     PastDateTime : DT := DT#2017-12-01-01:23:34;
> > > > >> > >     CurrentDateTime : DT;
> > > > >> > >     BOOL_TO_WORD15_OUT : WORD;
> > > > >> > >
> > > > >> > >   END_VAR
> > > > >> > >
> > > > >> > >   Y0 := NOT(Y0);
> > > > >> > >   BOOL_TO_WORD15_OUT := BOOL_TO_WORD(Y0);
> > > > >> > >   MBReg0 := BOOL_TO_WORD15_OUT;
> > > > >> > >   LED0 := NOT(Y0);
> > > > >> > >   MenuPar1 := Y0;
> > > > >> > >   LED1 := Y0;
> > > > >> > >   RTC0(PDT := PastDateTime);
> > > > >> > >   CurrentDateTime := RTC0.CDT;
> > > > >> > >
> > > > >> > > END_PROGRAM
> > > > >> > >
> > > > >> > >
> > > > >> > > CONFIGURATION config
> > > > >> > >
> > > > >> > >   VAR_GLOBAL
> > > > >> > >
> > > > >> > >     LED0 AT %QX4.0 : BOOL := True;
> > > > >> > >     LED1 AT %QX4.1 : BOOL := False;
> > > > >> > >     MBConf AT %QX2.1.9600.0 : BOOL := True;
> > > > >> > >     MBReg0 AT %MW2.0 : WORD := 0;
> > > > >> > >     MenuPar1 AT %MX4.1.3 : BOOL := 0;
> > > > >> > >     MenuPar2 AT %MX4.1.4 : BOOL := 0;
> > > > >> > >     DateVar : DT := DT#2017-12-01-01:23:34;
> > > > >> > >
> > > > >> > >   END_VAR
> > > > >> > >
> > > > >> > >   RESOURCE resource1 ON PLC
> > > > >> > >
> > > > >> > >     TASK Timer_500ms(INTERVAL := T#500ms,PRIORITY := 0);
> > > > >> > >     PROGRAM Blink_Task WITH Timer_500ms : Blink;
> > > > >> > >
> > > > >> > >   END_RESOURCE
> > > > >> > >
> > > > >> > > END_CONFIGURATION
> > > > >> >
> > > > >> > Best regards,
> > > > >> > Paul Beltyukov
> > > > >>
> > > > >> ------------------------------------------------------------
> > > > ------------------
> > > > >> Check out the vibrant tech community on one of the world's most
> > > > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > >> _______________________________________________
> > > > >> Beremiz-devel mailing list
> > > > >> [hidden email]
> > > > >> https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > > > >
> > > > > ------------------------------------------------------------
> > > > ------------------
> > > > > Check out the vibrant tech community on one of the world's most
> > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > >
> > > > > _______________________________________________
> > > > > Beremiz-devel mailing list
> > > > > [hidden email]
> > > > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > > >
> > > >
> > > > ------------------------------------------------------------
> > > > ------------------
> > > > Check out the vibrant tech community on one of the world's most
> > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > _______________________________________________
> > > > Beremiz-devel mailing list
> > > > [hidden email]
> > > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > > >
> >
> > > ------------------------------------------------------------
> > ------------------
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> > > _______________________________________________
> > > Beremiz-devel mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> >
> >
> > --
> > Best regards,
> > Andrey Skvortsov
> >
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Beremiz-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> >
> >

> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> _______________________________________________
> Beremiz-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/beremiz-devel


--
Best regards,
Andrey Skvortsov

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list


  OK. I will leave it as it is for now.

 Ideally we should not be using the temporary variable, but changing that is
quite a bit of work.


  Cheers,

       Mario.





On Wednesday 10 May 2017 12:36:48 [hidden email] wrote:

> Well, I consider it static initializer more evil: stack is "dynamic", so we
> can use "one storage" for all initializers,
> in case of static var the memory usage will be [bold]LARGER[/bold], so we
> get memory space overflow earlier.
>
> Best regards,
> Paul Beltyukov
>
> 2017-05-10 16:16 GMT+05:00 <[hidden email]>:
> > On 17-05-10 16:09, [hidden email] wrote:
> > > Hi, Andrey!
> > >
> > > How about:
> > >   #define __INIT_GLOBAL(type, name, initial, retained)\
> > >  
> > > >     {\
> > > >    
> > > >         __INIT_VAL_ATTR##type type temp =  initial;\
> > > >         __INIT_GLOBAL_##name(temp);\
> > > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > > >    
> > > >     }
> > >
> > > ?
> > >
> > > The main quecstion is how do we generate __INIT_VAL_ATTR##type,
> > > C-preprocessor doesn't have __define :(
> >
> > What do you think about making local variable static as it was before
> > (but not const)?
> >
> > static type temp = initial;
> >
> > > Best regards,
> > > Paul Beltyukov
> > >
> > > 2017-05-10 14:58 GMT+05:00 <[hidden email]>:
> > > > On 17-05-10 11:45, [hidden email] wrote:
> > > > > Hi!
> > > > >
> > > > > Thank you, Mario! The only remaining question is:
> > > > >
> > > > > What if "type" is some huge structure?
> > > > >
> > > > > I think there may be a possibility of stack overflow...
> > > > >
> > > > > What can other developers say on such hypothetical isssue?
> > > >
> > > > I've done some investigations.
> > > > I wrote some simple example to test this hypothetical issue.
> > > > Flash addresses are like 0x80000000, RAM addresses are 0x20000000.
> > > >
> > > > [------------------ main.c ------------------------]
> > > > struct a {
> > > >
> > > >         int x;
> > > >         int y;
> > > >
> > > > };
> > > >
> > > > struct a var2;
> > > >
> > > > void test_func(void)
> > > > {
> > > >
> > > >         struct a var1 = { 1, 2 };
> > > >         var2 = var1;
> > > >
> > > > }
> > > >
> > > >
> > > > int main(void)
> > > > {
> > > >
> > > >         test_func();
> > > >         for(;;);
> > > >
> > > > }
> > > > [---------------------------------------------------]
> > > >
> > > > Compiled with arm-none-eabi-gcc (GNU Tools for ARM Embedded
> > > > Processors) 5.2.1 20151202 (release) [ARM/embedded-5-branch revision
> > > > 231848]
> > > >
> > > > using following command:
> > > > arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -O2 -lc -lgcc -lnosys
> > > > -Wl,-Map=output.map -o main.elf main.c
> > > >
> > > >
> > > > [----------- assembler listing ----------------------]
> > > >
> > > > 0800111c <test_func>:
> > > >  800111c:       4b02            ldr     r3, [pc, #8]    ; (8001128
> > > >
> > > > <test_func+0xc>)
> > > >
> > > >  800111e:       2201            movs    r2, #1
> > > >  8001120:       601a            str     r2, [r3, #0]
> > > >  8001122:       2202            movs    r2, #2
> > > >  8001124:       605a            str     r2, [r3, #4]
> > > >  8001126:       4770            bx      lr
> > > >  8001128:       2000045c        andcs   r0, r0, ip, asr r4
> > > >
> > > > [---------------------------------------------------]
> > > >
> > > > output.map doesn't contain any reference to var1.
> > > >
> > > > See, no stack manipulation. var1 is optimized out and var2 is
> > > > initialized directly.
> > > >
> > > > with -Os and -O1 results are similar. var1 is optimized out. You
> > > > probably already use one of these flags.
> > > >
> > > >
> > > >
> > > > I tried the same with big structure (30 fields and total size 120
> > > > bytes). Here the picture is different. For big structures gcc starts
> > > > to use temporary variable on stack with any level of optimizations.
> > > >
> > > > [----------- assembler listing ----------------------]
> > > >
> > > > 0800111c <test_func>:
> > > >  800111c:       b510            push    {r4, lr}
> > > >  800111e:       b09e            sub     sp, #120        ; 0x78
> > > >  8001120:       2478            movs    r4, #120        ; 0x78
> > > >  8001122:       4622            mov     r2, r4
> > > >  8001124:       4905            ldr     r1, [pc, #20]   ; (800113c
> > > >
> > > > <test_func+0x20>)
> > > >
> > > >  8001126:       4668            mov     r0, sp
> > > >  8001128:       f000 f810       bl      800114c <memcpy>
> > > >  800112c:       4622            mov     r2, r4
> > > >  800112e:       4669            mov     r1, sp
> > > >  8001130:       4803            ldr     r0, [pc, #12]   ; (8001140
> > > >
> > > > <test_func+0x24>)
> > > >
> > > >  8001132:       f000 f80b       bl      800114c <memcpy>
> > > >  8001136:       b01e            add     sp, #120        ; 0x78
> > > >  8001138:       bd10            pop     {r4, pc}
> > > >  800113a:       bf00            nop
> > > >  800113c:       08001554        stmdaeq r0, {r2, r4, r6, r8, sl, ip}
> > > >  8001140:       2000045c        andcs   r0, r0, ip, asr r4
> > > >
> > > > [---------------------------------------------------]
> > > >
> > > > Actual problem with previous implementation was 'const', if I drop
> > > > 'const', but leave 'static' in place, then all things are good again
> > > > with -O1, -O2, -O3, -Ofast, -Os and even with -Og.
> > > >
> > > > [----------- assembler listing ----------------------]
> > > >
> > > > 0800111c <test_func>:
> > > >  800111c:       b508            push    {r3, lr}
> > > >  800111e:       2278            movs    r2, #120        ; 0x78
> > > >  8001120:       4902            ldr     r1, [pc, #8]    ; (800112c
> > > >
> > > > <test_func+0x10>)
> > > >
> > > >  8001122:       4803            ldr     r0, [pc, #12]   ; (8001130
> > > >
> > > > <test_func+0x14>)
> > > >
> > > >  8001124:       f000 f80a       bl      800113c <memcpy>
> > > >  8001128:       bd08            pop     {r3, pc}
> > > >  800112a:       bf00            nop
> > > >  800112c:       08001544        stmdaeq r0, {r2, r6, r8, sl, ip}
> > > >  8001130:       2000045c        andcs   r0, r0, ip, asr r4
> > > >
> > > > [---------------------------------------------------]
> > > >
> > > > var1 is optimized, gcc uses memcpy and copies data from flash.
> > > > No stack, no temporary variables.
> > > >
> > > > Unfortunately when no optimization level is selected (default is
> > > > -O0),
> >
> > then
> >
> > > > memory consumption is doubled because all these temporary variables
> > > > are static and are placed in .data section.
> > > >
> > > > I'm not very happy with making temporary variable 'static', because
> > > > without optimizations it'll double memory consumption for big
> >
> > structures.
> >
> > > > But I don't like stack overflows either on low-memory targets.
> > > >
> > > > What do you think about that? Can we do better?
> > > >
> > > > > Best regards,
> > > > > Paul Beltyukov
> > > > >
> > > > > 2017-05-10 1:49 GMT+05:00 <[hidden email]>:
> > > > > >   I pushed Paul's bug fix to my repository.
> > > > > >   http://bitbucket.org/mjsousa/matiec
> > > > > >  
> > > > > >   Paul, do let me know if I messed up anything.
> > > > > >  
> > > > > >    Cheers,
> > > > > >    
> > > > > >           Mario
> > > > > >
> > > > > > On 09.05.2017 10:49, [hidden email] wrote:
> > > > > > > On 17-05-09 10:39, [hidden email] wrote:
> > > > > > >>  Good catch Paul!
> > > > > > >>  
> > > > > > >>  The static const was only there to try and save time
> > > > > > >>  (execution
> > > >
> > > > time)
> > > >
> > > > > > >> and
> > > > > > >> space (memory). Using static const would get the variable
> >
> > placed in
> >
> > > > > > >> the
> > > > > > >> initiliazed data segment, so it would not need to be
> >
> > initialized at
> >
> > > > > > >> runtime.
> > > > > > >>
> > > > > > >>  This optimization is so tiny that I see no problem whatsoever
> >
> > in
> >
> > > > > > >> removing it.
> > > > > > >>
> > > > > > >>  Does anybody see any issue with this proposed change?
> > > > > > >
> > > > > > > Hi, Mario,
> > > > > > > I think gcc will make this optimization anyway for constant
> >
> > values.
> >
> > > > > > >> On Tuesday 09 May 2017 07:13:14 beremiz-devel@lists.
> >
> > sourceforge.net
> >
> > > > > > >> wrote:
> > > > > > >> > Hi!
> > > > > > >> >
> > > > > > >> > There is an issue with globals initialization in matiec,
> > > > > > >> > when
> >
> > DT
> >
> > > > > > global
> > > > > >
> > > > > > >> > variable is declared, the generated code id good, but it
> > > > > > >> > won't
> > > > > >
> > > > > > compile as
> > > > > >
> > > > > > >> > accessor.h has erronious definition:
> > > > > > >> >
> > > > > > >> > #define __INIT_GLOBAL(type, name, initial, retained)\
> > > > > > >> >
> > > > > > >> > >     {\
> > > > > > >> > >    
> > > > > > >> > >         static const type temp = initial;\
> > > > > > >> > >         __INIT_GLOBAL_##name(temp);\
> > > > > > >> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > > > > > >> > >    
> > > > > > >> > >     }
> > > > > > >> >
> > > > > > >> > which accept only constant expression for "initial"
> > > > > > >> > argument!
> > > > > > >> >
> > > > > > >> > So if we declare global DateVar : DT :=
> >
> > DT#2017-12-01-01:23:34;
> >
> > > > then
> > > >
> > > > > > >> > initial argument will be  __dt_to_timespec(34, 23, 1, 1, 12,
> >
> > 2017)
> >
> > > > > > which is
> > > > > >
> > > > > > >> > obviously is not constant.
> > > > > > >> >
> > > > > > >> > I propose the folowing definition:
> > > > > > >> > > #define __INIT_GLOBAL(type, name, initial, retained)\
> > > > > > >> > >
> > > > > > >> > >     {\
> > > > > > >> > >    
> > > > > > >> > >         type temp = initial;\
> > > > > > >> > >         __INIT_GLOBAL_##name(temp);\
> > > > > > >> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > > > > > >> > >    
> > > > > > >> > >     }
> > > > > > >> >
> > > > > > >> > Here is my test program:
> > > > > > >> > > PROGRAM Blink
> > > > > > >> > >
> > > > > > >> > >   VAR
> > > > > > >> > >  
> > > > > > >> > >     Y0 : BOOL;
> > > > > > >> > >  
> > > > > > >> > >   END_VAR
> > > > > > >> > >   VAR_EXTERNAL
> > > > > > >> > >  
> > > > > > >> > >     LED0 : BOOL;
> > > > > > >> > >     LED1 : BOOL;
> > > > > > >> > >     MBReg0 : WORD;
> > > > > > >> > >     MenuPar1 : BOOL;
> > > > > > >> > >  
> > > > > > >> > >   END_VAR
> > > > > > >> > >   VAR
> > > > > > >> > >  
> > > > > > >> > >     RTC0 : RTC;
> > > > > > >> > >     PastDateTime : DT := DT#2017-12-01-01:23:34;
> > > > > > >> > >     CurrentDateTime : DT;
> > > > > > >> > >     BOOL_TO_WORD15_OUT : WORD;
> > > > > > >> > >  
> > > > > > >> > >   END_VAR
> > > > > > >> > >  
> > > > > > >> > >   Y0 := NOT(Y0);
> > > > > > >> > >   BOOL_TO_WORD15_OUT := BOOL_TO_WORD(Y0);
> > > > > > >> > >   MBReg0 := BOOL_TO_WORD15_OUT;
> > > > > > >> > >   LED0 := NOT(Y0);
> > > > > > >> > >   MenuPar1 := Y0;
> > > > > > >> > >   LED1 := Y0;
> > > > > > >> > >   RTC0(PDT := PastDateTime);
> > > > > > >> > >   CurrentDateTime := RTC0.CDT;
> > > > > > >> > >
> > > > > > >> > > END_PROGRAM
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > CONFIGURATION config
> > > > > > >> > >
> > > > > > >> > >   VAR_GLOBAL
> > > > > > >> > >  
> > > > > > >> > >     LED0 AT %QX4.0 : BOOL := True;
> > > > > > >> > >     LED1 AT %QX4.1 : BOOL := False;
> > > > > > >> > >     MBConf AT %QX2.1.9600.0 : BOOL := True;
> > > > > > >> > >     MBReg0 AT %MW2.0 : WORD := 0;
> > > > > > >> > >     MenuPar1 AT %MX4.1.3 : BOOL := 0;
> > > > > > >> > >     MenuPar2 AT %MX4.1.4 : BOOL := 0;
> > > > > > >> > >     DateVar : DT := DT#2017-12-01-01:23:34;
> > > > > > >> > >  
> > > > > > >> > >   END_VAR
> > > > > > >> > >  
> > > > > > >> > >   RESOURCE resource1 ON PLC
> > > > > > >> > >  
> > > > > > >> > >     TASK Timer_500ms(INTERVAL := T#500ms,PRIORITY := 0);
> > > > > > >> > >     PROGRAM Blink_Task WITH Timer_500ms : Blink;
> > > > > > >> > >  
> > > > > > >> > >   END_RESOURCE
> > > > > > >> > >
> > > > > > >> > > END_CONFIGURATION
> > > > > > >> >
> > > > > > >> > Best regards,
> > > > > > >> > Paul Beltyukov
> > > > > > >>
> > > > > > >> ------------------------------------------------------------
> > > > > >
> > > > > > ------------------
> > > > > >
> > > > > > >> Check out the vibrant tech community on one of the world's
> > > > > > >> most engaging tech sites, Slashdot.org!
> > > > > > >> http://sdm.link/slashdot
> > > > > > >> _______________________________________________
> > > > > > >> Beremiz-devel mailing list
> > > > > > >> [hidden email]
> > > > > > >> https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > > > > > >
> > > > > > > ------------------------------------------------------------
> > > > > >
> > > > > > ------------------
> > > > > >
> > > > > > > Check out the vibrant tech community on one of the world's most
> > > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Beremiz-devel mailing list
> > > > > > > [hidden email]
> > > > > > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > > > > >
> > > > > > ------------------------------------------------------------
> > > > > > ------------------
> > > > > > Check out the vibrant tech community on one of the world's most
> > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > > > _______________________________________________
> > > > > > Beremiz-devel mailing list
> > > > > > [hidden email]
> > > > > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > > > >
> > > > > ------------------------------------------------------------
> > > >
> > > > ------------------
> > > >
> > > > > Check out the vibrant tech community on one of the world's most
> > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > >
> > > > > _______________________________________________
> > > > > Beremiz-devel mailing list
> > > > > [hidden email]
> > > > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > > >
> > > > --
> > > > Best regards,
> > > > Andrey Skvortsov
> > > >
> > > > ------------------------------------------------------------
> > > > ------------------
> > > > Check out the vibrant tech community on one of the world's most
> > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > _______________________________________________
> > > > Beremiz-devel mailing list
> > > > [hidden email]
> > > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > >
> > > ------------------------------------------------------------
> >
> > ------------------
> >
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > >
> > > _______________________________________________
> > > Beremiz-devel mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> >
> > --
> > Best regards,
> > Andrey Skvortsov
> >
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Beremiz-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/beremiz-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
On 17-05-10 16:36, [hidden email] wrote:
> Well, I consider it static initializer more evil: stack is "dynamic", so we
> can use "one storage" for all initializers,

In general, I agree with you about static variables. It maybe not that
safe as variable on stack. I'm trying to find the way achieve the same
with less changes to matiec.


> in case of static var the memory usage will be [bold]LARGER[/bold], so we
> get memory space overflow earlier.
not completely true.

As I said on non-low-memory target memory consumption is the same as before with
'static const' and probably the same as with temporary variable on
stack. Because initial read-only values have to be in RAM somewhere
anyway (there is no addressed flash on these platforms). Here we are ok.

On low-memory targets in my example gcc optimizes out temporary static
local variable at any optimization level (of course, except -O0, no
optimization). So *no* additional RAM memory is used. Initial values are
copied directly *from flash*. And *no* stack is used. Exactly what we wanted.
The main question is will this optimization take place for *all* cases
__INIT_GLOBAL or maybe there are some corner cases.


> Best regards,
> Paul Beltyukov
>
> 2017-05-10 16:16 GMT+05:00 <[hidden email]>:
>
> > On 17-05-10 16:09, [hidden email] wrote:
> > > Hi, Andrey!
> > >
> > > How about:
> > >
> > >   #define __INIT_GLOBAL(type, name, initial, retained)\
> > > >     {\
> > > >         __INIT_VAL_ATTR##type type temp =  initial;\
> > > >         __INIT_GLOBAL_##name(temp);\
> > > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > > >     }
> > > >
> > > ?
> > >
> > > The main quecstion is how do we generate __INIT_VAL_ATTR##type,
> > > C-preprocessor doesn't have __define :(
> >
> > What do you think about making local variable static as it was before
> > (but not const)?
> >
> > static type temp = initial;
> >
> >
> >
> > > Best regards,
> > > Paul Beltyukov
> > >
> > > 2017-05-10 14:58 GMT+05:00 <[hidden email]>:
> > >
> > > > On 17-05-10 11:45, [hidden email] wrote:
> > > > > Hi!
> > > > >
> > > > > Thank you, Mario! The only remaining question is:
> > > > >
> > > > > What if "type" is some huge structure?
> > > > >
> > > > > I think there may be a possibility of stack overflow...
> > > > >
> > > > > What can other developers say on such hypothetical isssue?
> > > >
> > > > I've done some investigations.
> > > > I wrote some simple example to test this hypothetical issue.
> > > > Flash addresses are like 0x80000000, RAM addresses are 0x20000000.
> > > >
> > > > [------------------ main.c ------------------------]
> > > > struct a {
> > > >         int x;
> > > >         int y;
> > > > };
> > > >
> > > > struct a var2;
> > > >
> > > > void test_func(void)
> > > > {
> > > >         struct a var1 = { 1, 2 };
> > > >         var2 = var1;
> > > > }
> > > >
> > > >
> > > > int main(void)
> > > > {
> > > >         test_func();
> > > >         for(;;);
> > > > }
> > > > [---------------------------------------------------]
> > > >
> > > > Compiled with arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors)
> > > > 5.2.1 20151202 (release) [ARM/embedded-5-branch revision 231848]
> > > >
> > > > using following command:
> > > > arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -O2 -lc -lgcc -lnosys
> > > > -Wl,-Map=output.map -o main.elf main.c
> > > >
> > > >
> > > > [----------- assembler listing ----------------------]
> > > > 0800111c <test_func>:
> > > >  800111c:       4b02            ldr     r3, [pc, #8]    ; (8001128
> > > > <test_func+0xc>)
> > > >  800111e:       2201            movs    r2, #1
> > > >  8001120:       601a            str     r2, [r3, #0]
> > > >  8001122:       2202            movs    r2, #2
> > > >  8001124:       605a            str     r2, [r3, #4]
> > > >  8001126:       4770            bx      lr
> > > >  8001128:       2000045c        andcs   r0, r0, ip, asr r4
> > > > [---------------------------------------------------]
> > > >
> > > > output.map doesn't contain any reference to var1.
> > > >
> > > > See, no stack manipulation. var1 is optimized out and var2 is
> > > > initialized directly.
> > > >
> > > > with -Os and -O1 results are similar. var1 is optimized out. You
> > > > probably already use one of these flags.
> > > >
> > > >
> > > >
> > > > I tried the same with big structure (30 fields and total size 120
> > > > bytes). Here the picture is different. For big structures gcc starts
> > > > to use temporary variable on stack with any level of optimizations.
> > > >
> > > > [----------- assembler listing ----------------------]
> > > > 0800111c <test_func>:
> > > >  800111c:       b510            push    {r4, lr}
> > > >  800111e:       b09e            sub     sp, #120        ; 0x78
> > > >  8001120:       2478            movs    r4, #120        ; 0x78
> > > >  8001122:       4622            mov     r2, r4
> > > >  8001124:       4905            ldr     r1, [pc, #20]   ; (800113c
> > > > <test_func+0x20>)
> > > >  8001126:       4668            mov     r0, sp
> > > >  8001128:       f000 f810       bl      800114c <memcpy>
> > > >  800112c:       4622            mov     r2, r4
> > > >  800112e:       4669            mov     r1, sp
> > > >  8001130:       4803            ldr     r0, [pc, #12]   ; (8001140
> > > > <test_func+0x24>)
> > > >  8001132:       f000 f80b       bl      800114c <memcpy>
> > > >  8001136:       b01e            add     sp, #120        ; 0x78
> > > >  8001138:       bd10            pop     {r4, pc}
> > > >  800113a:       bf00            nop
> > > >  800113c:       08001554        stmdaeq r0, {r2, r4, r6, r8, sl, ip}
> > > >  8001140:       2000045c        andcs   r0, r0, ip, asr r4
> > > > [---------------------------------------------------]
> > > >
> > > > Actual problem with previous implementation was 'const', if I drop
> > > > 'const', but leave 'static' in place, then all things are good again
> > > > with -O1, -O2, -O3, -Ofast, -Os and even with -Og.
> > > >
> > > > [----------- assembler listing ----------------------]
> > > > 0800111c <test_func>:
> > > >  800111c:       b508            push    {r3, lr}
> > > >  800111e:       2278            movs    r2, #120        ; 0x78
> > > >  8001120:       4902            ldr     r1, [pc, #8]    ; (800112c
> > > > <test_func+0x10>)
> > > >  8001122:       4803            ldr     r0, [pc, #12]   ; (8001130
> > > > <test_func+0x14>)
> > > >  8001124:       f000 f80a       bl      800113c <memcpy>
> > > >  8001128:       bd08            pop     {r3, pc}
> > > >  800112a:       bf00            nop
> > > >  800112c:       08001544        stmdaeq r0, {r2, r6, r8, sl, ip}
> > > >  8001130:       2000045c        andcs   r0, r0, ip, asr r4
> > > > [---------------------------------------------------]
> > > >
> > > > var1 is optimized, gcc uses memcpy and copies data from flash.
> > > > No stack, no temporary variables.
> > > >
> > > > Unfortunately when no optimization level is selected (default is -O0),
> > then
> > > > memory consumption is doubled because all these temporary variables
> > > > are static and are placed in .data section.
> > > >
> > > > I'm not very happy with making temporary variable 'static', because
> > > > without optimizations it'll double memory consumption for big
> > structures.
> > > > But I don't like stack overflows either on low-memory targets.
> > > >
> > > > What do you think about that? Can we do better?
> > > >
> > > > > Best regards,
> > > > > Paul Beltyukov
> > > > >
> > > > > 2017-05-10 1:49 GMT+05:00 <[hidden email]>:
> > > > >
> > > > > >
> > > > > >
> > > > > >   I pushed Paul's bug fix to my repository.
> > > > > >   http://bitbucket.org/mjsousa/matiec
> > > > > >
> > > > > >   Paul, do let me know if I messed up anything.
> > > > > >
> > > > > >
> > > > > >    Cheers,
> > > > > >
> > > > > >           Mario
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 09.05.2017 10:49, [hidden email] wrote:
> > > > > > > On 17-05-09 10:39, [hidden email] wrote:
> > > > > > >>
> > > > > > >>
> > > > > > >>  Good catch Paul!
> > > > > > >>
> > > > > > >>  The static const was only there to try and save time (execution
> > > > time)
> > > > > > >> and
> > > > > > >> space (memory). Using static const would get the variable
> > placed in
> > > > > > >> the
> > > > > > >> initiliazed data segment, so it would not need to be
> > initialized at
> > > > > > >> runtime.
> > > > > > >>
> > > > > > >>  This optimization is so tiny that I see no problem whatsoever
> > in
> > > > > > >> removing it.
> > > > > > >>
> > > > > > >>  Does anybody see any issue with this proposed change?
> > > > > > >
> > > > > > > Hi, Mario,
> > > > > > > I think gcc will make this optimization anyway for constant
> > values.
> > > > > > >
> > > > > > >>
> > > > > > >> On Tuesday 09 May 2017 07:13:14 beremiz-devel@lists.
> > sourceforge.net
> > > > > > >> wrote:
> > > > > > >> > Hi!
> > > > > > >> >
> > > > > > >> > There is an issue with globals initialization in matiec, when
> > DT
> > > > > > global
> > > > > > >> > variable is declared, the generated code id good, but it won't
> > > > > > compile as
> > > > > > >> > accessor.h has erronious definition:
> > > > > > >> >
> > > > > > >> > #define __INIT_GLOBAL(type, name, initial, retained)\
> > > > > > >> >
> > > > > > >> > >     {\
> > > > > > >> > >
> > > > > > >> > >         static const type temp = initial;\
> > > > > > >> > >         __INIT_GLOBAL_##name(temp);\
> > > > > > >> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > > > > > >> > >
> > > > > > >> > >     }
> > > > > > >> >
> > > > > > >> > which accept only constant expression for "initial" argument!
> > > > > > >> >
> > > > > > >> > So if we declare global DateVar : DT :=
> > DT#2017-12-01-01:23:34;
> > > > then
> > > > > > >> > initial argument will be  __dt_to_timespec(34, 23, 1, 1, 12,
> > 2017)
> > > > > > which is
> > > > > > >> > obviously is not constant.
> > > > > > >> >
> > > > > > >> > I propose the folowing definition:
> > > > > > >> > > #define __INIT_GLOBAL(type, name, initial, retained)\
> > > > > > >> > >
> > > > > > >> > >     {\
> > > > > > >> > >
> > > > > > >> > >         type temp = initial;\
> > > > > > >> > >         __INIT_GLOBAL_##name(temp);\
> > > > > > >> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > > > > > >> > >
> > > > > > >> > >     }
> > > > > > >> >
> > > > > > >> > Here is my test program:
> > > > > > >> > > PROGRAM Blink
> > > > > > >> > >
> > > > > > >> > >   VAR
> > > > > > >> > >
> > > > > > >> > >     Y0 : BOOL;
> > > > > > >> > >
> > > > > > >> > >   END_VAR
> > > > > > >> > >   VAR_EXTERNAL
> > > > > > >> > >
> > > > > > >> > >     LED0 : BOOL;
> > > > > > >> > >     LED1 : BOOL;
> > > > > > >> > >     MBReg0 : WORD;
> > > > > > >> > >     MenuPar1 : BOOL;
> > > > > > >> > >
> > > > > > >> > >   END_VAR
> > > > > > >> > >   VAR
> > > > > > >> > >
> > > > > > >> > >     RTC0 : RTC;
> > > > > > >> > >     PastDateTime : DT := DT#2017-12-01-01:23:34;
> > > > > > >> > >     CurrentDateTime : DT;
> > > > > > >> > >     BOOL_TO_WORD15_OUT : WORD;
> > > > > > >> > >
> > > > > > >> > >   END_VAR
> > > > > > >> > >
> > > > > > >> > >   Y0 := NOT(Y0);
> > > > > > >> > >   BOOL_TO_WORD15_OUT := BOOL_TO_WORD(Y0);
> > > > > > >> > >   MBReg0 := BOOL_TO_WORD15_OUT;
> > > > > > >> > >   LED0 := NOT(Y0);
> > > > > > >> > >   MenuPar1 := Y0;
> > > > > > >> > >   LED1 := Y0;
> > > > > > >> > >   RTC0(PDT := PastDateTime);
> > > > > > >> > >   CurrentDateTime := RTC0.CDT;
> > > > > > >> > >
> > > > > > >> > > END_PROGRAM
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > CONFIGURATION config
> > > > > > >> > >
> > > > > > >> > >   VAR_GLOBAL
> > > > > > >> > >
> > > > > > >> > >     LED0 AT %QX4.0 : BOOL := True;
> > > > > > >> > >     LED1 AT %QX4.1 : BOOL := False;
> > > > > > >> > >     MBConf AT %QX2.1.9600.0 : BOOL := True;
> > > > > > >> > >     MBReg0 AT %MW2.0 : WORD := 0;
> > > > > > >> > >     MenuPar1 AT %MX4.1.3 : BOOL := 0;
> > > > > > >> > >     MenuPar2 AT %MX4.1.4 : BOOL := 0;
> > > > > > >> > >     DateVar : DT := DT#2017-12-01-01:23:34;
> > > > > > >> > >
> > > > > > >> > >   END_VAR
> > > > > > >> > >
> > > > > > >> > >   RESOURCE resource1 ON PLC
> > > > > > >> > >
> > > > > > >> > >     TASK Timer_500ms(INTERVAL := T#500ms,PRIORITY := 0);
> > > > > > >> > >     PROGRAM Blink_Task WITH Timer_500ms : Blink;
> > > > > > >> > >
> > > > > > >> > >   END_RESOURCE
> > > > > > >> > >
> > > > > > >> > > END_CONFIGURATION
> > > > > > >> >
> > > > > > >> > Best regards,
> > > > > > >> > Paul Beltyukov

--
Best regards,
Andrey Skvortsov

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
On 17-05-10 16:27, [hidden email] wrote:
>
>
>   OK. I will leave it as it is for now.
>
>  Ideally we should not be using the temporary variable, but changing that is
> quite a bit of work.

Hi Mario,


this exactly that I want to suggest.
What do you think about this:

#define __INIT_GLOBAL(type, name, initial, retained)\
     {\
         __INIT_GLOBAL_##name((type)initial);\
         __INIT_RETAIN((*GLOBAL__##name), retained)\
     }

I see that temporary variable was introduced to handle array
initialization by 60b012b7793f (Adding support for compiling direct
array specification inside variable declaration).
I checked array initialization, structure initialization,
initialization of array of structures. These cases do work.

What could be a problem?

>
> On Wednesday 10 May 2017 12:36:48 [hidden email] wrote:
> > Well, I consider it static initializer more evil: stack is "dynamic", so we
> > can use "one storage" for all initializers,
> > in case of static var the memory usage will be [bold]LARGER[/bold], so we
> > get memory space overflow earlier.
> >
> > Best regards,
> > Paul Beltyukov
> >
> > 2017-05-10 16:16 GMT+05:00 <[hidden email]>:
> > > On 17-05-10 16:09, [hidden email] wrote:
> > > > Hi, Andrey!
> > > >
> > > > How about:
> > > >   #define __INIT_GLOBAL(type, name, initial, retained)\
> > > >  
> > > > >     {\
> > > > >    
> > > > >         __INIT_VAL_ATTR##type type temp =  initial;\
> > > > >         __INIT_GLOBAL_##name(temp);\
> > > > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > > > >    
> > > > >     }
> > > >
> > > > ?
> > > >
> > > > The main quecstion is how do we generate __INIT_VAL_ATTR##type,
> > > > C-preprocessor doesn't have __define :(
> > >
> > > What do you think about making local variable static as it was before
> > > (but not const)?
> > >
> > > static type temp = initial;
> > >
> > > > Best regards,
> > > > Paul Beltyukov
> > > >
> > > > 2017-05-10 14:58 GMT+05:00 <[hidden email]>:
> > > > > On 17-05-10 11:45, [hidden email] wrote:
> > > > > > Hi!
> > > > > >
> > > > > > Thank you, Mario! The only remaining question is:
> > > > > >
> > > > > > What if "type" is some huge structure?
> > > > > >
> > > > > > I think there may be a possibility of stack overflow...
> > > > > >
> > > > > > What can other developers say on such hypothetical isssue?
> > > > >
> > > > > I've done some investigations.
> > > > > I wrote some simple example to test this hypothetical issue.
> > > > > Flash addresses are like 0x80000000, RAM addresses are 0x20000000.
> > > > >
> > > > > [------------------ main.c ------------------------]
> > > > > struct a {
> > > > >
> > > > >         int x;
> > > > >         int y;
> > > > >
> > > > > };
> > > > >
> > > > > struct a var2;
> > > > >
> > > > > void test_func(void)
> > > > > {
> > > > >
> > > > >         struct a var1 = { 1, 2 };
> > > > >         var2 = var1;
> > > > >
> > > > > }
> > > > >
> > > > >
> > > > > int main(void)
> > > > > {
> > > > >
> > > > >         test_func();
> > > > >         for(;;);
> > > > >
> > > > > }
> > > > > [---------------------------------------------------]
> > > > >
> > > > > Compiled with arm-none-eabi-gcc (GNU Tools for ARM Embedded
> > > > > Processors) 5.2.1 20151202 (release) [ARM/embedded-5-branch revision
> > > > > 231848]
> > > > >
> > > > > using following command:
> > > > > arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -O2 -lc -lgcc -lnosys
> > > > > -Wl,-Map=output.map -o main.elf main.c
> > > > >
> > > > >
> > > > > [----------- assembler listing ----------------------]
> > > > >
> > > > > 0800111c <test_func>:
> > > > >  800111c:       4b02            ldr     r3, [pc, #8]    ; (8001128
> > > > >
> > > > > <test_func+0xc>)
> > > > >
> > > > >  800111e:       2201            movs    r2, #1
> > > > >  8001120:       601a            str     r2, [r3, #0]
> > > > >  8001122:       2202            movs    r2, #2
> > > > >  8001124:       605a            str     r2, [r3, #4]
> > > > >  8001126:       4770            bx      lr
> > > > >  8001128:       2000045c        andcs   r0, r0, ip, asr r4
> > > > >
> > > > > [---------------------------------------------------]
> > > > >
> > > > > output.map doesn't contain any reference to var1.
> > > > >
> > > > > See, no stack manipulation. var1 is optimized out and var2 is
> > > > > initialized directly.
> > > > >
> > > > > with -Os and -O1 results are similar. var1 is optimized out. You
> > > > > probably already use one of these flags.
> > > > >
> > > > >
> > > > >
> > > > > I tried the same with big structure (30 fields and total size 120
> > > > > bytes). Here the picture is different. For big structures gcc starts
> > > > > to use temporary variable on stack with any level of optimizations.
> > > > >
> > > > > [----------- assembler listing ----------------------]
> > > > >
> > > > > 0800111c <test_func>:
> > > > >  800111c:       b510            push    {r4, lr}
> > > > >  800111e:       b09e            sub     sp, #120        ; 0x78
> > > > >  8001120:       2478            movs    r4, #120        ; 0x78
> > > > >  8001122:       4622            mov     r2, r4
> > > > >  8001124:       4905            ldr     r1, [pc, #20]   ; (800113c
> > > > >
> > > > > <test_func+0x20>)
> > > > >
> > > > >  8001126:       4668            mov     r0, sp
> > > > >  8001128:       f000 f810       bl      800114c <memcpy>
> > > > >  800112c:       4622            mov     r2, r4
> > > > >  800112e:       4669            mov     r1, sp
> > > > >  8001130:       4803            ldr     r0, [pc, #12]   ; (8001140
> > > > >
> > > > > <test_func+0x24>)
> > > > >
> > > > >  8001132:       f000 f80b       bl      800114c <memcpy>
> > > > >  8001136:       b01e            add     sp, #120        ; 0x78
> > > > >  8001138:       bd10            pop     {r4, pc}
> > > > >  800113a:       bf00            nop
> > > > >  800113c:       08001554        stmdaeq r0, {r2, r4, r6, r8, sl, ip}
> > > > >  8001140:       2000045c        andcs   r0, r0, ip, asr r4
> > > > >
> > > > > [---------------------------------------------------]
> > > > >
> > > > > Actual problem with previous implementation was 'const', if I drop
> > > > > 'const', but leave 'static' in place, then all things are good again
> > > > > with -O1, -O2, -O3, -Ofast, -Os and even with -Og.
> > > > >
> > > > > [----------- assembler listing ----------------------]
> > > > >
> > > > > 0800111c <test_func>:
> > > > >  800111c:       b508            push    {r3, lr}
> > > > >  800111e:       2278            movs    r2, #120        ; 0x78
> > > > >  8001120:       4902            ldr     r1, [pc, #8]    ; (800112c
> > > > >
> > > > > <test_func+0x10>)
> > > > >
> > > > >  8001122:       4803            ldr     r0, [pc, #12]   ; (8001130
> > > > >
> > > > > <test_func+0x14>)
> > > > >
> > > > >  8001124:       f000 f80a       bl      800113c <memcpy>
> > > > >  8001128:       bd08            pop     {r3, pc}
> > > > >  800112a:       bf00            nop
> > > > >  800112c:       08001544        stmdaeq r0, {r2, r6, r8, sl, ip}
> > > > >  8001130:       2000045c        andcs   r0, r0, ip, asr r4
> > > > >
> > > > > [---------------------------------------------------]
> > > > >
> > > > > var1 is optimized, gcc uses memcpy and copies data from flash.
> > > > > No stack, no temporary variables.
> > > > >
> > > > > Unfortunately when no optimization level is selected (default is
> > > > > -O0),
> > >
> > > then
> > >
> > > > > memory consumption is doubled because all these temporary variables
> > > > > are static and are placed in .data section.
> > > > >
> > > > > I'm not very happy with making temporary variable 'static', because
> > > > > without optimizations it'll double memory consumption for big
> > >
> > > structures.
> > >
> > > > > But I don't like stack overflows either on low-memory targets.
> > > > >
> > > > > What do you think about that? Can we do better?
> > > > >
> > > > > > Best regards,
> > > > > > Paul Beltyukov
> > > > > >
> > > > > > 2017-05-10 1:49 GMT+05:00 <[hidden email]>:
> > > > > > >   I pushed Paul's bug fix to my repository.
> > > > > > >   http://bitbucket.org/mjsousa/matiec
> > > > > > >  
> > > > > > >   Paul, do let me know if I messed up anything.
> > > > > > >  
> > > > > > >    Cheers,
> > > > > > >    
> > > > > > >           Mario
> > > > > > >
> > > > > > > On 09.05.2017 10:49, [hidden email] wrote:
> > > > > > > > On 17-05-09 10:39, [hidden email] wrote:
> > > > > > > >>  Good catch Paul!
> > > > > > > >>  
> > > > > > > >>  The static const was only there to try and save time
> > > > > > > >>  (execution
> > > > >
> > > > > time)
> > > > >
> > > > > > > >> and
> > > > > > > >> space (memory). Using static const would get the variable
> > >
> > > placed in
> > >
> > > > > > > >> the
> > > > > > > >> initiliazed data segment, so it would not need to be
> > >
> > > initialized at
> > >
> > > > > > > >> runtime.
> > > > > > > >>
> > > > > > > >>  This optimization is so tiny that I see no problem whatsoever
> > >
> > > in
> > >
> > > > > > > >> removing it.
> > > > > > > >>
> > > > > > > >>  Does anybody see any issue with this proposed change?
> > > > > > > >
> > > > > > > > Hi, Mario,
> > > > > > > > I think gcc will make this optimization anyway for constant
> > >
> > > values.
> > >
> > > > > > > >> On Tuesday 09 May 2017 07:13:14 beremiz-devel@lists.
> > >
> > > sourceforge.net
> > >
> > > > > > > >> wrote:
> > > > > > > >> > Hi!
> > > > > > > >> >
> > > > > > > >> > There is an issue with globals initialization in matiec,
> > > > > > > >> > when
> > >
> > > DT
> > >
> > > > > > > global
> > > > > > >
> > > > > > > >> > variable is declared, the generated code id good, but it
> > > > > > > >> > won't
> > > > > > >
> > > > > > > compile as
> > > > > > >
> > > > > > > >> > accessor.h has erronious definition:
> > > > > > > >> >
> > > > > > > >> > #define __INIT_GLOBAL(type, name, initial, retained)\
> > > > > > > >> >
> > > > > > > >> > >     {\
> > > > > > > >> > >    
> > > > > > > >> > >         static const type temp = initial;\
> > > > > > > >> > >         __INIT_GLOBAL_##name(temp);\
> > > > > > > >> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > > > > > > >> > >    
> > > > > > > >> > >     }
> > > > > > > >> >
> > > > > > > >> > which accept only constant expression for "initial"
> > > > > > > >> > argument!
> > > > > > > >> >
> > > > > > > >> > So if we declare global DateVar : DT :=
> > >
> > > DT#2017-12-01-01:23:34;
> > >
> > > > > then
> > > > >
> > > > > > > >> > initial argument will be  __dt_to_timespec(34, 23, 1, 1, 12,
> > >
> > > 2017)
> > >
> > > > > > > which is
> > > > > > >
> > > > > > > >> > obviously is not constant.
> > > > > > > >> >
> > > > > > > >> > I propose the folowing definition:
> > > > > > > >> > > #define __INIT_GLOBAL(type, name, initial, retained)\
> > > > > > > >> > >
> > > > > > > >> > >     {\
> > > > > > > >> > >    
> > > > > > > >> > >         type temp = initial;\
> > > > > > > >> > >         __INIT_GLOBAL_##name(temp);\
> > > > > > > >> > >         __INIT_RETAIN((*GLOBAL__##name), retained)\
> > > > > > > >> > >    
> > > > > > > >> > >     }
> > > > > > > >> >
> > > > > > > >> > Here is my test program:
> > > > > > > >> > > PROGRAM Blink
> > > > > > > >> > >
> > > > > > > >> > >   VAR
> > > > > > > >> > >  
> > > > > > > >> > >     Y0 : BOOL;
> > > > > > > >> > >  
> > > > > > > >> > >   END_VAR
> > > > > > > >> > >   VAR_EXTERNAL
> > > > > > > >> > >  
> > > > > > > >> > >     LED0 : BOOL;
> > > > > > > >> > >     LED1 : BOOL;
> > > > > > > >> > >     MBReg0 : WORD;
> > > > > > > >> > >     MenuPar1 : BOOL;
> > > > > > > >> > >  
> > > > > > > >> > >   END_VAR
> > > > > > > >> > >   VAR
> > > > > > > >> > >  
> > > > > > > >> > >     RTC0 : RTC;
> > > > > > > >> > >     PastDateTime : DT := DT#2017-12-01-01:23:34;
> > > > > > > >> > >     CurrentDateTime : DT;
> > > > > > > >> > >     BOOL_TO_WORD15_OUT : WORD;
> > > > > > > >> > >  
> > > > > > > >> > >   END_VAR
> > > > > > > >> > >  
> > > > > > > >> > >   Y0 := NOT(Y0);
> > > > > > > >> > >   BOOL_TO_WORD15_OUT := BOOL_TO_WORD(Y0);
> > > > > > > >> > >   MBReg0 := BOOL_TO_WORD15_OUT;
> > > > > > > >> > >   LED0 := NOT(Y0);
> > > > > > > >> > >   MenuPar1 := Y0;
> > > > > > > >> > >   LED1 := Y0;
> > > > > > > >> > >   RTC0(PDT := PastDateTime);
> > > > > > > >> > >   CurrentDateTime := RTC0.CDT;
> > > > > > > >> > >
> > > > > > > >> > > END_PROGRAM
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > > CONFIGURATION config
> > > > > > > >> > >
> > > > > > > >> > >   VAR_GLOBAL
> > > > > > > >> > >  
> > > > > > > >> > >     LED0 AT %QX4.0 : BOOL := True;
> > > > > > > >> > >     LED1 AT %QX4.1 : BOOL := False;
> > > > > > > >> > >     MBConf AT %QX2.1.9600.0 : BOOL := True;
> > > > > > > >> > >     MBReg0 AT %MW2.0 : WORD := 0;
> > > > > > > >> > >     MenuPar1 AT %MX4.1.3 : BOOL := 0;
> > > > > > > >> > >     MenuPar2 AT %MX4.1.4 : BOOL := 0;
> > > > > > > >> > >     DateVar : DT := DT#2017-12-01-01:23:34;
> > > > > > > >> > >  
> > > > > > > >> > >   END_VAR
> > > > > > > >> > >  
> > > > > > > >> > >   RESOURCE resource1 ON PLC
> > > > > > > >> > >  
> > > > > > > >> > >     TASK Timer_500ms(INTERVAL := T#500ms,PRIORITY := 0);
> > > > > > > >> > >     PROGRAM Blink_Task WITH Timer_500ms : Blink;
> > > > > > > >> > >  
> > > > > > > >> > >   END_RESOURCE
> > > > > > > >> > >
> > > > > > > >> > > END_CONFIGURATION
> > > > > > > >> >
> > > > > > > >> > Best regards,
> > > > > > > >> > Paul Beltyukov
> > > > > > > >>
> > > > > > > >> ------------------------------------------------------------
> > > > > > >
> > > > > > > ------------------
> > > > > > >
> > > > > > > >> Check out the vibrant tech community on one of the world's
> > > > > > > >> most engaging tech sites, Slashdot.org!
> > > > > > > >> http://sdm.link/slashdot
> > > > > > > >> _______________________________________________
> > > > > > > >> Beremiz-devel mailing list
> > > > > > > >> [hidden email]
> > > > > > > >> https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > > > > > > >
> > > > > > > > ------------------------------------------------------------
> > > > > > >
> > > > > > > ------------------
> > > > > > >
> > > > > > > > Check out the vibrant tech community on one of the world's most
> > > > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Beremiz-devel mailing list
> > > > > > > > [hidden email]
> > > > > > > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > > > > > >
> > > > > > > ------------------------------------------------------------
> > > > > > > ------------------
> > > > > > > Check out the vibrant tech community on one of the world's most
> > > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > > > > _______________________________________________
> > > > > > > Beremiz-devel mailing list
> > > > > > > [hidden email]
> > > > > > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > > > > >
> > > > > > ------------------------------------------------------------
> > > > >
> > > > > ------------------
> > > > >
> > > > > > Check out the vibrant tech community on one of the world's most
> > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > > >
> > > > > > _______________________________________________
> > > > > > Beremiz-devel mailing list
> > > > > > [hidden email]
> > > > > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Andrey Skvortsov
> > > > >
> > > > > ------------------------------------------------------------
> > > > > ------------------
> > > > > Check out the vibrant tech community on one of the world's most
> > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > > _______________________________________________
> > > > > Beremiz-devel mailing list
> > > > > [hidden email]
> > > > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > > >
> > > > ------------------------------------------------------------
> > >
> > > ------------------
> > >
> > > > Check out the vibrant tech community on one of the world's most
> > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > >
> > > > _______________________________________________
> > > > Beremiz-devel mailing list
> > > > [hidden email]
> > > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
> > >
> > > --
> > > Best regards,
> > > Andrey Skvortsov
> > >
> > > ------------------------------------------------------------
> > > ------------------
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > _______________________________________________
> > > Beremiz-devel mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Beremiz-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/beremiz-devel
--
Best regards,
Andrey Skvortsov

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list



 Hi Paul,



On Wednesday 10 May 2017 17:58:54 [hidden email] wrote:

> On 17-05-10 16:27, [hidden email] wrote:
> >   OK. I will leave it as it is for now.
> >  
> >  Ideally we should not be using the temporary variable, but changing that
> >  is
> >
> > quite a bit of work.
>
> Hi Mario,
>
>
> this exactly that I want to suggest.
> What do you think about this:
>
> #define __INIT_GLOBAL(type, name, initial, retained)\
>      {\
>          __INIT_GLOBAL_##name((type)initial);\
>          __INIT_RETAIN((*GLOBAL__##name), retained)\
>      }
>
> I see that temporary variable was introduced to handle array
> initialization by 60b012b7793f (Adding support for compiling direct
> array specification inside variable declaration).
> I checked array initialization, structure initialization,
> initialization of array of structures. These cases do work.
>
> What could be a problem?
>

  To be honest, I do not really know. There are too many details to remember
them all. I would need to look at it again in detail to figure it out.

 The "direct array specification inside variable declaration" is when you have
something like:

  VAR
     anon_array_var: ARRAY [1..5] OF INT;
 END_VAR


 At the moment matiec creates a datatype (with a made up name) for this
anonymous type, but I think (I am not sure) the first version of matiec to
support this was slightly different. It could be that the temp variable is no
longer needed, but I would need to make a thorough analysis to make sure.


  Mario.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list
On 17-05-10 19:00, [hidden email] wrote:

>
>
>
>  Hi Paul,
>
>
>
> On Wednesday 10 May 2017 17:58:54 [hidden email] wrote:
> > On 17-05-10 16:27, [hidden email] wrote:
> > >   OK. I will leave it as it is for now.
> > >  
> > >  Ideally we should not be using the temporary variable, but changing that
> > >  is
> > >
> > > quite a bit of work.
> >
> > Hi Mario,
> >
> >
> > this exactly that I want to suggest.
> > What do you think about this:
> >
> > #define __INIT_GLOBAL(type, name, initial, retained)\
> >      {\
> >          __INIT_GLOBAL_##name((type)initial);\
> >          __INIT_RETAIN((*GLOBAL__##name), retained)\
> >      }
> >
> > I see that temporary variable was introduced to handle array
> > initialization by 60b012b7793f (Adding support for compiling direct
> > array specification inside variable declaration).
> > I checked array initialization, structure initialization,
> > initialization of array of structures. These cases do work.
> >
> > What could be a problem?
> >
>
>   To be honest, I do not really know. There are too many details to remember
> them all. I would need to look at it again in detail to figure it out.
>
>  The "direct array specification inside variable declaration" is when you have
> something like:
>
>   VAR
>      anon_array_var: ARRAY [1..5] OF INT;
>  END_VAR
I checked this. This is working.


>  At the moment matiec creates a datatype (with a made up name) for this
> anonymous type, but I think (I am not sure) the first version of matiec to
> support this was slightly different. It could be that the temp variable is no
> longer needed, but I would need to make a thorough analysis to make sure.
>
This would be nice.


--
Best regards,
Andrey Skvortsov



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] Bug, matiec, iecstdlib, globals initialization.

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
On 17-05-10 19:00, [hidden email] wrote:
>
>
>
>  Hi Paul,
This was actually Andrey. ;-)

>
> On Wednesday 10 May 2017 17:58:54 [hidden email] wrote:
> > On 17-05-10 16:27, [hidden email] wrote:
> > >   OK. I will leave it as it is for now.
> > >  
> > >  Ideally we should not be using the temporary variable, but changing that
> > >  is
> > >
> > > quite a bit of work.
> >
> > Hi Mario,
> >
> >
> > this exactly that I want to suggest.
> > What do you think about this:
> >
> > #define __INIT_GLOBAL(type, name, initial, retained)\
> >      {\
> >          __INIT_GLOBAL_##name((type)initial);\
> >          __INIT_RETAIN((*GLOBAL__##name), retained)\
> >      }
> >
> > I see that temporary variable was introduced to handle array
> > initialization by 60b012b7793f (Adding support for compiling direct
> > array specification inside variable declaration).
> > I checked array initialization, structure initialization,
> > initialization of array of structures. These cases do work.
> >
> > What could be a problem?
> >
>
>   To be honest, I do not really know. There are too many details to remember
> them all. I would need to look at it again in detail to figure it out.
>
>  The "direct array specification inside variable declaration" is when you have
> something like:
>
>   VAR
>      anon_array_var: ARRAY [1..5] OF INT;
>  END_VAR
>
>
>  At the moment matiec creates a datatype (with a made up name) for this
> anonymous type, but I think (I am not sure) the first version of matiec to
> support this was slightly different. It could be that the temp variable is no
> longer needed, but I would need to make a thorough analysis to make sure.


--
Best regards,
Andrey Skvortsov



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Beremiz-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/beremiz-devel

signature.asc (849 bytes) Download Attachment