[Beremiz-devel] sizeof({DT,TIME,DATE})

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

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
Hi Mario,


On 17-06-02 16:30, [hidden email] wrote:

> On Friday 02 June 2017 08:03:53 [hidden email] wrote:
> > Hi, Andrey!
> >
> > I think disabling locations for time related types is good temporary
> > solution.
> >
> > I also think that using uint64_t for timespec is HARD decision:
> >   - on one hand in may solve some problems in long term;
>
>  I would be OK with this being a permanent solution.
>
>  Since the standard:
>    - does not specify a size for the DT data type
>        (may be implementation specific)
>    - implicitly mandates that located variables should match
>        the size of the location
>
if we are going to fix the problem (and I hope we are), then the
question is do we *really* want to keep size of DT the same? If we
don't care about size of DT, then the easiest way would be just to
increase size of 'tv_sec' field to 'uint64_t'. This will keep most
parts of the existing matiec code the same. Some changes to
iec_std_lib are needed, but they are easy and obvious.

struct timespec {
        uint64_t tv_sec;        /* seconds */
        long     tv_nsec;       /* nanoseconds */
};

64-bit integer value for seconds is already used in:
- OpenBSD/NetBSD;
- x32 ABI for GNU/Linux (32-bit API on 64-bit systems);
- all 64-bit GNU/Linux systems.

There is ongoing work to add 64-bit seconds support to 32-bit
GNU/Linux systems for all architectures. This will be added most
likely through new syscall.



>   then I conclude that the standard is OK with not allowing located DT
> variables.
>
>
>
> >   - but one the other hand it requires MUCH work on matiec and iec_std_lib,
> >     and it also breaks backward compatibility.
> >
>
>
>  To be honest this is something that has been bothering me too, but since I do
> not use beremiz/matiec in a professional setting, I have never bothered fixing
> it.
>
>
>  Yes, the iec_std_lib.h library would need to be fixed. This is kind of
> obvious, but I will say it anyway: we would need to, at a minimum, change the
> conversion functions, as well as the basic functions doing DT algebra
> (mutiply, add, subtract, ...). We would also need to change some macros that
> handle the DT constants, as well as the variable declaration itself.
>
>  I think that matiec itself should be OK. Hmm.... Thinking a little more, it
> may require some changes to matiec. More specifically, we will need to change
> the way matiec initializes DT variables.
>
>
>
>
> > So I would not recomend to take so radical approach :)
> >
>
>
>    Yes, that is why some of the matiec code is terrible. Because the people
> writing it were afraid of making big changes.
> Sometimes radical changes are
> needed, sometimes not. In this case I think if we are going to fix this, then
> we should do it correctly.
Mario, did you thought about testing infrastructure for matiec?
I see matiec already has test directory with some tests. Do you use
it?


--
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] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
On Friday 02 June 2017 17:20:07 [hidden email] wrote:

> Hi Mario,
>
> On 17-06-02 16:30, [hidden email] wrote:
> > On Friday 02 June 2017 08:03:53 [hidden email] wrote:
> > > Hi, Andrey!
> > >
> > > I think disabling locations for time related types is good temporary
> > > solution.
> > >
> > > I also think that using uint64_t for timespec is HARD decision:
> > >   - on one hand in may solve some problems in long term;
> >  
> >  I would be OK with this being a permanent solution.
> >  
> >  Since the standard:
> >    - does not specify a size for the DT data type
> >    
> >        (may be implementation specific)
> >    
> >    - implicitly mandates that located variables should match
> >    
> >        the size of the location
>
> if we are going to fix the problem (and I hope we are), then the
> question is do we *really* want to keep size of DT the same? If we
> don't care about size of DT, then the easiest way would be just to
> increase size of 'tv_sec' field to 'uint64_t'. This will keep most
> parts of the existing matiec code the same. Some changes to
> iec_std_lib are needed, but they are easy and obvious.
>
> struct timespec {
>         uint64_t tv_sec;        /* seconds */
>         long     tv_nsec;       /* nanoseconds */
> };
>
> 64-bit integer value for seconds is already used in:
> - OpenBSD/NetBSD;
> - x32 ABI for GNU/Linux (32-bit API on 64-bit systems);
> - all 64-bit GNU/Linux systems.
>
> There is ongoing work to add 64-bit seconds support to 32-bit
> GNU/Linux systems for all architectures. This will be added most
> likely through new syscall.
>


  Yes. I have no problem with changing the size of DT. Then again, I am not
using this in an industrial setting. Maybe other people would have a problem?

 I like this method. As you say, with any luck matiec itself would not need to
change at all. I would actually suggest, if we are going to change this, to
change the tv_nsec too, so we can have a fixed sized of DT.


struct timespec {
        uint64_t tv_sec;        /* seconds */
        uint32_t tv_nsec;       /* nanoseconds */
};


>
> Mario, did you thought about testing infrastructure for matiec?
> I see matiec already has test directory with some tests. Do you use
> it?

 I once started trying to code up a modular testing infra-structure, but never
really got around to doing it.
 At the moment I have a private (i.e. not in the repository) testing directory
with some 20-30 test files. Every time I add a new feature or fix a bug I add a
new test case. However, I run these tests manually (just a very basic
makefile). Never got around to automating it...


  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] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
Hi,Mario!

struct timespec {
        uint64_t tv_sec;        /* seconds */
        uint32_t tv_nsec;       /* nanoseconds */
};

What about dates earlier that 1970 in case of uint we will lost them!
And how do we going to deal with substruction of time related types?

I think signed types are better in our case.

And yes, Mario, it would be really good if you add the tests with some basic usage and coding instructions to your repo.
In such case other developers would be able to run tests before sending you patches,
we even may get more regression tests from other people :)

Best regards,
Paul Beltyukov

2017-06-02 23:53 GMT+05:00 <[hidden email]>:
On Friday 02 June 2017 17:20:07 [hidden email] wrote:
> Hi Mario,
>
> On 17-06-02 16:30, [hidden email] wrote:
> > On Friday 02 June 2017 08:03:53 [hidden email] wrote:
> > > Hi, Andrey!
> > >
> > > I think disabling locations for time related types is good temporary
> > > solution.
> > >
> > > I also think that using uint64_t for timespec is HARD decision:
> > >   - on one hand in may solve some problems in long term;
> >
> >  I would be OK with this being a permanent solution.
> >
> >  Since the standard:
> >    - does not specify a size for the DT data type
> >
> >        (may be implementation specific)
> >
> >    - implicitly mandates that located variables should match
> >
> >        the size of the location
>
> if we are going to fix the problem (and I hope we are), then the
> question is do we *really* want to keep size of DT the same? If we
> don't care about size of DT, then the easiest way would be just to
> increase size of 'tv_sec' field to 'uint64_t'. This will keep most
> parts of the existing matiec code the same. Some changes to
> iec_std_lib are needed, but they are easy and obvious.
>
> struct timespec {
>         uint64_t tv_sec;        /* seconds */
>         long     tv_nsec;       /* nanoseconds */
> };
>
> 64-bit integer value for seconds is already used in:
> - OpenBSD/NetBSD;
> - x32 ABI for GNU/Linux (32-bit API on 64-bit systems);
> - all 64-bit GNU/Linux systems.
>
> There is ongoing work to add 64-bit seconds support to 32-bit
> GNU/Linux systems for all architectures. This will be added most
> likely through new syscall.
>


  Yes. I have no problem with changing the size of DT. Then again, I am not
using this in an industrial setting. Maybe other people would have a problem?

 I like this method. As you say, with any luck matiec itself would not need to
change at all. I would actually suggest, if we are going to change this, to
change the tv_nsec too, so we can have a fixed sized of DT.


struct timespec {
        uint64_t tv_sec;        /* seconds */
        uint32_t tv_nsec;       /* nanoseconds */
};


>
> Mario, did you thought about testing infrastructure for matiec?
> I see matiec already has test directory with some tests. Do you use
> it?

 I once started trying to code up a modular testing infra-structure, but never
really got around to doing it.
 At the moment I have a private (i.e. not in the repository) testing directory
with some 20-30 test files. Every time I add a new feature or fix a bug I add a
new test case. However, I run these tests manually (just a very basic
makefile). Never got around to automating it...


  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


------------------------------------------------------------------------------
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] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
How are we going to deal with...

Sorry my english, it's late now...

Regards,
Paul

2017-06-04 23:48 GMT+05:00 <[hidden email]>:
Hi,Mario!

struct timespec {
        uint64_t tv_sec;        /* seconds */
        uint32_t tv_nsec;       /* nanoseconds */
};

What about dates earlier that 1970 in case of uint we will lost them!
And how do we going to deal with substruction of time related types?

I think signed types are better in our case.

And yes, Mario, it would be really good if you add the tests with some basic usage and coding instructions to your repo.
In such case other developers would be able to run tests before sending you patches,
we even may get more regression tests from other people :)

Best regards,
Paul Beltyukov

2017-06-02 23:53 GMT+05:00 <[hidden email]>:
On Friday 02 June 2017 17:20:07 [hidden email] wrote:
> Hi Mario,
>
> On 17-06-02 16:30, [hidden email] wrote:
> > On Friday 02 June 2017 08:03:53 [hidden email] wrote:
> > > Hi, Andrey!
> > >
> > > I think disabling locations for time related types is good temporary
> > > solution.
> > >
> > > I also think that using uint64_t for timespec is HARD decision:
> > >   - on one hand in may solve some problems in long term;
> >
> >  I would be OK with this being a permanent solution.
> >
> >  Since the standard:
> >    - does not specify a size for the DT data type
> >
> >        (may be implementation specific)
> >
> >    - implicitly mandates that located variables should match
> >
> >        the size of the location
>
> if we are going to fix the problem (and I hope we are), then the
> question is do we *really* want to keep size of DT the same? If we
> don't care about size of DT, then the easiest way would be just to
> increase size of 'tv_sec' field to 'uint64_t'. This will keep most
> parts of the existing matiec code the same. Some changes to
> iec_std_lib are needed, but they are easy and obvious.
>
> struct timespec {
>         uint64_t tv_sec;        /* seconds */
>         long     tv_nsec;       /* nanoseconds */
> };
>
> 64-bit integer value for seconds is already used in:
> - OpenBSD/NetBSD;
> - x32 ABI for GNU/Linux (32-bit API on 64-bit systems);
> - all 64-bit GNU/Linux systems.
>
> There is ongoing work to add 64-bit seconds support to 32-bit
> GNU/Linux systems for all architectures. This will be added most
> likely through new syscall.
>


  Yes. I have no problem with changing the size of DT. Then again, I am not
using this in an industrial setting. Maybe other people would have a problem?

 I like this method. As you say, with any luck matiec itself would not need to
change at all. I would actually suggest, if we are going to change this, to
change the tv_nsec too, so we can have a fixed sized of DT.


struct timespec {
        uint64_t tv_sec;        /* seconds */
        uint32_t tv_nsec;       /* nanoseconds */
};


>
> Mario, did you thought about testing infrastructure for matiec?
> I see matiec already has test directory with some tests. Do you use
> it?

 I once started trying to code up a modular testing infra-structure, but never
really got around to doing it.
 At the moment I have a private (i.e. not in the repository) testing directory
with some 20-30 test files. Every time I add a new feature or fix a bug I add a
new test case. However, I run these tests manually (just a very basic
makefile). Never got around to automating it...


  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


------------------------------------------------------------------------------
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] sizeof({DT,TIME,DATE})

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

On 17-06-04 23:48, [hidden email] wrote:
> >   Yes. I have no problem with changing the size of DT. Then again, I am not
> > using this in an industrial setting. Maybe other people would have a
> > problem?

Sure. Let's have a discussion first and only than make some such changes.
I CC'd Eduard, Denis and Tomaz. Hopefully they have some feedback.
Guys, what do you think about this problem and currently suggested solution?

Actually everyone is welcome.


> struct timespec {
> >         uint64_t tv_sec;        /* seconds */
> >         uint32_t tv_nsec;       /* nanoseconds */
> > };
>
>
> What about dates earlier that 1970 in case of uint we will lost them!
> And how do we going to deal with substruction of time related types?

I agree with Paul, that tv_sec and tv_nsec should be signed types.

type_initial_value.cc contains following comment:

  /* FIXME: Our current implementation only allows dates from 1970 onwards,
   * but the standard defines the date 0001-01-01 as the default value
   * for the DATE data type. Untill we fix our implementation, we use 1970-01-01
   * as our default value!!
   */

with signed 64bit integer for tv_sec it's possible to represent
required by the standard initial value for DT and DATE types
(D#0001-01-01, section 2.3.3.2)



> 2017-06-02 23:53 GMT+05:00 <[hidden email]>:
>
> > On Friday 02 June 2017 17:20:07 [hidden email] wrote:
> > > Hi Mario,
> > >
> > > On 17-06-02 16:30, [hidden email] wrote:
> > > > On Friday 02 June 2017 08:03:53 [hidden email]
> > wrote:
> > > > > Hi, Andrey!
> > > > >
> > > > > I think disabling locations for time related types is good temporary
> > > > > solution.
> > > > >
> > > > > I also think that using uint64_t for timespec is HARD decision:
> > > > >   - on one hand in may solve some problems in long term;
> > > >
> > > >  I would be OK with this being a permanent solution.
> > > >
> > > >  Since the standard:
> > > >    - does not specify a size for the DT data type
> > > >
> > > >        (may be implementation specific)
> > > >
> > > >    - implicitly mandates that located variables should match
> > > >
> > > >        the size of the location
> > >
> > > if we are going to fix the problem (and I hope we are), then the
> > > question is do we *really* want to keep size of DT the same? If we
> > > don't care about size of DT, then the easiest way would be just to
> > > increase size of 'tv_sec' field to 'uint64_t'. This will keep most
> > > parts of the existing matiec code the same. Some changes to
> > > iec_std_lib are needed, but they are easy and obvious.
> > >
> > > struct timespec {
> > >         uint64_t tv_sec;        /* seconds */
> > >         long     tv_nsec;       /* nanoseconds */
> > > };
> > >
> > > 64-bit integer value for seconds is already used in:
> > > - OpenBSD/NetBSD;
> > > - x32 ABI for GNU/Linux (32-bit API on 64-bit systems);
> > > - all 64-bit GNU/Linux systems.
> > >
> > > There is ongoing work to add 64-bit seconds support to 32-bit
> > > GNU/Linux systems for all architectures. This will be added most
> > > likely through new syscall.
> > >
> >
> >
> >  I like this method. As you say, with any luck matiec itself would not
> > need to
> > change at all. I would actually suggest, if we are going to change this, to
> > change the tv_nsec too, so we can have a fixed sized of DT.
Some small changes will be necessary, because iec_std_lib.h contains a
lot of typecastings to 'long int'. This has to be fixed.


> > struct timespec {
> >         uint64_t tv_sec;        /* seconds */
> >         uint32_t tv_nsec;       /* nanoseconds */
> > };
> >
> >

--
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] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list

Hi!

We don't really use DT much, it's usually more about counters, etc., but this is going to change on the new controller (schedules are used a lot). The old one (MC8, microcontroller) still uses ancient gcc (arm-none-eabi-gcc 4.7.2 from Yagarto), but I think it should still work.

I don't see too much of a problem if users need to open, fix and rebuild some old PLC projects with DT. If it's more than that, there will be complaints...


Tomaz Orac
R&D SW manager, SMARTEH d.o.o.

On 06. 06. 2017 16:31, Andrey Skvortsov wrote:
Hi Mario,

On 17-06-04 23:48, [hidden email] wrote:
  Yes. I have no problem with changing the size of DT. Then again, I am not
using this in an industrial setting. Maybe other people would have a
problem?
Sure. Let's have a discussion first and only than make some such changes.
I CC'd Eduard, Denis and Tomaz. Hopefully they have some feedback.
Guys, what do you think about this problem and currently suggested solution?

Actually everyone is welcome.


struct timespec {
        uint64_t tv_sec;        /* seconds */
        uint32_t tv_nsec;       /* nanoseconds */
};

What about dates earlier that 1970 in case of uint we will lost them!
And how do we going to deal with substruction of time related types?
I agree with Paul, that tv_sec and tv_nsec should be signed types.

type_initial_value.cc contains following comment:

  /* FIXME: Our current implementation only allows dates from 1970 onwards,
   * but the standard defines the date 0001-01-01 as the default value
   * for the DATE data type. Untill we fix our implementation, we use 1970-01-01
   * as our default value!!
   */

with signed 64bit integer for tv_sec it's possible to represent
required by the standard initial value for DT and DATE types
(D#0001-01-01, section 2.3.3.2)



2017-06-02 23:53 GMT+05:00 [hidden email]:

On Friday 02 June 2017 17:20:07 [hidden email] wrote:
Hi Mario,

On 17-06-02 16:30, [hidden email] wrote:
On Friday 02 June 2017 08:03:53 [hidden email]
wrote:
Hi, Andrey!

I think disabling locations for time related types is good temporary
solution.

I also think that using uint64_t for timespec is HARD decision:
  - on one hand in may solve some problems in long term;
 I would be OK with this being a permanent solution.

 Since the standard:
   - does not specify a size for the DT data type

       (may be implementation specific)

   - implicitly mandates that located variables should match

       the size of the location
if we are going to fix the problem (and I hope we are), then the
question is do we *really* want to keep size of DT the same? If we
don't care about size of DT, then the easiest way would be just to
increase size of 'tv_sec' field to 'uint64_t'. This will keep most
parts of the existing matiec code the same. Some changes to
iec_std_lib are needed, but they are easy and obvious.

struct timespec {
        uint64_t tv_sec;        /* seconds */
        long     tv_nsec;       /* nanoseconds */
};

64-bit integer value for seconds is already used in:
- OpenBSD/NetBSD;
- x32 ABI for GNU/Linux (32-bit API on 64-bit systems);
- all 64-bit GNU/Linux systems.

There is ongoing work to add 64-bit seconds support to 32-bit
GNU/Linux systems for all architectures. This will be added most
likely through new syscall.


 I like this method. As you say, with any luck matiec itself would not
need to
change at all. I would actually suggest, if we are going to change this, to
change the tv_nsec too, so we can have a fixed sized of DT.
Some small changes will be necessary, because iec_std_lib.h contains a
lot of typecastings to 'long int'. This has to be fixed.


struct timespec {
        uint64_t tv_sec;        /* seconds */
        uint32_t tv_nsec;       /* nanoseconds */
};



    


------------------------------------------------------------------------------
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] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
On 17-06-07 15:49, [hidden email] wrote:
> Hi!
>
> We don't really use DT much, it's usually more about counters, etc., but
> this is going to change on the new controller (schedules are used a
> lot).

Hi Tomaz,

thank you for the answer. Not only DT is affected, but DATE, TIME and
TOD types. Because all these types are the same struct IEC_TIMESPEC
internally.

You say you don't use DT, but you probably use timers (TON, TOF, TP).
They use TIME and therefore rely on IEC_TIMESPEC.



> The old one (MC8, microcontroller) still uses ancient gcc (arm-none-eabi-gcc
> 4.7.2 from Yagarto), but I think it should still work.

> I don't see too much of a problem if users need to open, fix and rebuild
> some old PLC projects with DT. If it's more than that, there will be
> complaints...

As always the answer is 'It depends'. If during build process of user
PLC application the program is built complete from scratch, then it's ok.
But if matiec generated source code is linked against precompiled
library, that uses IEC_TIMESPEC, then it could be a problem. For
example, PLC_GetTime.

Tomaz, do you use precompiled library to build PLC program?
Do you struct IEC_TIMESPEC in other places than PLC_GetTime?
Do you have any plans on solving 2038y issue?



Guys,

what do you think if the IEC_TIMESPEC structure will look like this:

struct timespec {
 int32_t tv_sec;        /* seconds */
 int32_t tv_nsec;       /* nanoseconds */
 int32_t tv_sec_ext;    /* high word for seconds */
};

In this case we have backward compatibility for old code, that access
structure using pointer. Do we have cases where IEC_TIMESPEC structure
is used as function argument by value?


> *Tomaz Orac*
> R&D SW manager, SMARTEH d.o.o.
>
> On 06. 06. 2017 16:31, Andrey Skvortsov wrote:
> > Hi Mario,
> >
> > On 17-06-04 23:48, [hidden email] wrote:
> > > >    Yes. I have no problem with changing the size of DT. Then again, I am not
> > > > using this in an industrial setting. Maybe other people would have a
> > > > problem?
> > Sure. Let's have a discussion first and only than make some such changes.
> > I CC'd Eduard, Denis and Tomaz. Hopefully they have some feedback.
> > Guys, what do you think about this problem and currently suggested solution?
> >
> > Actually everyone is welcome.
> >
> >
> > > struct timespec {
> > > >          uint64_t tv_sec;        /* seconds */
> > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > };
> > >
> > > What about dates earlier that 1970 in case of uint we will lost them!
> > > And how do we going to deal with substruction of time related types?
> > I agree with Paul, that tv_sec and tv_nsec should be signed types.
> >
> > type_initial_value.cc contains following comment:
> >
> >    /* FIXME: Our current implementation only allows dates from 1970 onwards,
> >     * but the standard defines the date 0001-01-01 as the default value
> >     * for the DATE data type. Untill we fix our implementation, we use 1970-01-01
> >     * as our default value!!
> >     */
> >
> > with signed 64bit integer for tv_sec it's possible to represent
> > required by the standard initial value for DT and DATE types
> > (D#0001-01-01, section 2.3.3.2)
> >
> >
> >
> > > 2017-06-02 23:53 GMT+05:00 <[hidden email]>:
> > >
> > > > On Friday 02 June 2017 17:20:07 [hidden email] wrote:
> > > > > Hi Mario,
> > > > >
> > > > > On 17-06-02 16:30, [hidden email] wrote:
> > > > > > On Friday 02 June 2017 08:03:53 [hidden email]
> > > > wrote:
> > > > > > > Hi, Andrey!
> > > > > > >
> > > > > > > I think disabling locations for time related types is good temporary
> > > > > > > solution.
> > > > > > >
> > > > > > > I also think that using uint64_t for timespec is HARD decision:
> > > > > > >    - on one hand in may solve some problems in long term;
> > > > > >   I would be OK with this being a permanent solution.
> > > > > >
> > > > > >   Since the standard:
> > > > > >     - does not specify a size for the DT data type
> > > > > >
> > > > > >         (may be implementation specific)
> > > > > >
> > > > > >     - implicitly mandates that located variables should match
> > > > > >
> > > > > >         the size of the location
> > > > > if we are going to fix the problem (and I hope we are), then the
> > > > > question is do we *really* want to keep size of DT the same? If we
> > > > > don't care about size of DT, then the easiest way would be just to
> > > > > increase size of 'tv_sec' field to 'uint64_t'. This will keep most
> > > > > parts of the existing matiec code the same. Some changes to
> > > > > iec_std_lib are needed, but they are easy and obvious.
> > > > >
> > > > > struct timespec {
> > > > >          uint64_t tv_sec;        /* seconds */
> > > > >          long     tv_nsec;       /* nanoseconds */
> > > > > };
> > > > >
> > > > > 64-bit integer value for seconds is already used in:
> > > > > - OpenBSD/NetBSD;
> > > > > - x32 ABI for GNU/Linux (32-bit API on 64-bit systems);
> > > > > - all 64-bit GNU/Linux systems.
> > > > >
> > > > > There is ongoing work to add 64-bit seconds support to 32-bit
> > > > > GNU/Linux systems for all architectures. This will be added most
> > > > > likely through new syscall.
> > > > >
> > > >
> > > >   I like this method. As you say, with any luck matiec itself would not
> > > > need to
> > > > change at all. I would actually suggest, if we are going to change this, to
> > > > change the tv_nsec too, so we can have a fixed sized of DT.
> > Some small changes will be necessary, because iec_std_lib.h contains a
> > lot of typecastings to 'long int'. This has to be fixed.
> >
> >
> > > > struct timespec {
> > > >          uint64_t tv_sec;        /* seconds */
> > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > };
> > > >
> > > >
>

> ------------------------------------------------------------------------------
> 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] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
Hi, Andrey!

How about:


#ifndef IEC_SEC_T
#define IEC_SEC_T long int
#endif
 
#ifndef IEC_NSEC_T
#define IEC_NSEC_T long int
#endif
 
typedef struct {
    IEC_SEC_T   tv_sec;            /* Seconds.  */
    IEC_NSEC_T tv_nsec;           /* Nanoseconds.  */
} /* __attribute__((packed)) */ IEC_TIMESPEC;  /* packed is gcc specific! */

In such case we have current implementation by default, and if we want to solve 2048 problem on new devices,
then we have to add -DIEC_SEC_T=int64_t -DIEC_NSEC_T=int32_t options when bilding C-code.

Best regards,
Paul Beltyukov

2017-06-09 15:22 GMT+05:00 <[hidden email]>:
On 17-06-07 15:49, [hidden email] wrote:
> Hi!
>
> We don't really use DT much, it's usually more about counters, etc., but
> this is going to change on the new controller (schedules are used a
> lot).

Hi Tomaz,

thank you for the answer. Not only DT is affected, but DATE, TIME and
TOD types. Because all these types are the same struct IEC_TIMESPEC
internally.

You say you don't use DT, but you probably use timers (TON, TOF, TP).
They use TIME and therefore rely on IEC_TIMESPEC.



> The old one (MC8, microcontroller) still uses ancient gcc (arm-none-eabi-gcc
> 4.7.2 from Yagarto), but I think it should still work.

> I don't see too much of a problem if users need to open, fix and rebuild
> some old PLC projects with DT. If it's more than that, there will be
> complaints...

As always the answer is 'It depends'. If during build process of user
PLC application the program is built complete from scratch, then it's ok.
But if matiec generated source code is linked against precompiled
library, that uses IEC_TIMESPEC, then it could be a problem. For
example, PLC_GetTime.

Tomaz, do you use precompiled library to build PLC program?
Do you struct IEC_TIMESPEC in other places than PLC_GetTime?
Do you have any plans on solving 2038y issue?



Guys,

what do you think if the IEC_TIMESPEC structure will look like this:

struct timespec {
 int32_t tv_sec;        /* seconds */
 int32_t tv_nsec;       /* nanoseconds */
 int32_t tv_sec_ext;    /* high word for seconds */
};

In this case we have backward compatibility for old code, that access
structure using pointer. Do we have cases where IEC_TIMESPEC structure
is used as function argument by value?


> *Tomaz Orac*
> R&D SW manager, SMARTEH d.o.o.
>
> On 06. 06. 2017 16:31, Andrey Skvortsov wrote:
> > Hi Mario,
> >
> > On 17-06-04 23:48, [hidden email] wrote:
> > > >    Yes. I have no problem with changing the size of DT. Then again, I am not
> > > > using this in an industrial setting. Maybe other people would have a
> > > > problem?
> > Sure. Let's have a discussion first and only than make some such changes.
> > I CC'd Eduard, Denis and Tomaz. Hopefully they have some feedback.
> > Guys, what do you think about this problem and currently suggested solution?
> >
> > Actually everyone is welcome.
> >
> >
> > > struct timespec {
> > > >          uint64_t tv_sec;        /* seconds */
> > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > };
> > >
> > > What about dates earlier that 1970 in case of uint we will lost them!
> > > And how do we going to deal with substruction of time related types?
> > I agree with Paul, that tv_sec and tv_nsec should be signed types.
> >
> > type_initial_value.cc contains following comment:
> >
> >    /* FIXME: Our current implementation only allows dates from 1970 onwards,
> >     * but the standard defines the date 0001-01-01 as the default value
> >     * for the DATE data type. Untill we fix our implementation, we use 1970-01-01
> >     * as our default value!!
> >     */
> >
> > with signed 64bit integer for tv_sec it's possible to represent
> > required by the standard initial value for DT and DATE types
> > (D#0001-01-01, section 2.3.3.2)
> >
> >
> >
> > > 2017-06-02 23:53 GMT+05:00 <[hidden email]>:
> > >
> > > > On Friday 02 June 2017 17:20:07 [hidden email] wrote:
> > > > > Hi Mario,
> > > > >
> > > > > On 17-06-02 16:30, [hidden email] wrote:
> > > > > > On Friday 02 June 2017 08:03:53 [hidden email]
> > > > wrote:
> > > > > > > Hi, Andrey!
> > > > > > >
> > > > > > > I think disabling locations for time related types is good temporary
> > > > > > > solution.
> > > > > > >
> > > > > > > I also think that using uint64_t for timespec is HARD decision:
> > > > > > >    - on one hand in may solve some problems in long term;
> > > > > >   I would be OK with this being a permanent solution.
> > > > > >
> > > > > >   Since the standard:
> > > > > >     - does not specify a size for the DT data type
> > > > > >
> > > > > >         (may be implementation specific)
> > > > > >
> > > > > >     - implicitly mandates that located variables should match
> > > > > >
> > > > > >         the size of the location
> > > > > if we are going to fix the problem (and I hope we are), then the
> > > > > question is do we *really* want to keep size of DT the same? If we
> > > > > don't care about size of DT, then the easiest way would be just to
> > > > > increase size of 'tv_sec' field to 'uint64_t'. This will keep most
> > > > > parts of the existing matiec code the same. Some changes to
> > > > > iec_std_lib are needed, but they are easy and obvious.
> > > > >
> > > > > struct timespec {
> > > > >          uint64_t tv_sec;        /* seconds */
> > > > >          long     tv_nsec;       /* nanoseconds */
> > > > > };
> > > > >
> > > > > 64-bit integer value for seconds is already used in:
> > > > > - OpenBSD/NetBSD;
> > > > > - x32 ABI for GNU/Linux (32-bit API on 64-bit systems);
> > > > > - all 64-bit GNU/Linux systems.
> > > > >
> > > > > There is ongoing work to add 64-bit seconds support to 32-bit
> > > > > GNU/Linux systems for all architectures. This will be added most
> > > > > likely through new syscall.
> > > > >
> > > >
> > > >   I like this method. As you say, with any luck matiec itself would not
> > > > need to
> > > > change at all. I would actually suggest, if we are going to change this, to
> > > > change the tv_nsec too, so we can have a fixed sized of DT.
> > Some small changes will be necessary, because iec_std_lib.h contains a
> > lot of typecastings to 'long int'. This has to be fixed.
> >
> >
> > > > struct timespec {
> > > >          uint64_t tv_sec;        /* seconds */
> > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > };
> > > >
> > > >
>

> ------------------------------------------------------------------------------
> 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] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
On 17-06-13 11:06, [hidden email] wrote:

> Hi, Andrey!
>
> How about:
>
>
> > #ifndef IEC_SEC_T
> > #define IEC_SEC_T long int
> > #endif
> >
> > #ifndef IEC_NSEC_T
> > #define IEC_NSEC_T long int
> > #endif
>
>
> >
> typedef struct {
> >     IEC_SEC_T   tv_sec;            /* Seconds.  */
> >     IEC_NSEC_T tv_nsec;           /* Nanoseconds.  */
> > } /* __attribute__((packed)) */ IEC_TIMESPEC;  /* packed is gcc specific!
> > */
> >
>
> In such case we have current implementation by default, and if we want to
> solve 2048 problem on new devices,
> then we have to add -DIEC_SEC_T=int64_t -DIEC_NSEC_T=int32_t options when
> bilding C-code.
It is obvious solution, but the problem is here. Some questions
are still open.
When we change the default size of IEC_SEC_T and IEC_NSEC_T to int64_t?
All newcomers will use default values, that would generate
problematic code and then later people will probably complain about
bad code generated by matiec.

IMHO this trick will work only if we change default values to int64_t
*now*. And people who cares about backward compatibility
can set IEC_SEC_T to int32_t by defines at compile time.


Paul, could you please say your opinion on my last suggested approach?

> 2017-06-09 15:22 GMT+05:00 <[hidden email]>:
>
> > On 17-06-07 15:49, [hidden email] wrote:
> > > Hi!
> > >
> > > We don't really use DT much, it's usually more about counters, etc., but
> > > this is going to change on the new controller (schedules are used a
> > > lot).
> >
> > Hi Tomaz,
> >
> > thank you for the answer. Not only DT is affected, but DATE, TIME and
> > TOD types. Because all these types are the same struct IEC_TIMESPEC
> > internally.
> >
> > You say you don't use DT, but you probably use timers (TON, TOF, TP).
> > They use TIME and therefore rely on IEC_TIMESPEC.
> >
> >
> >
> > > The old one (MC8, microcontroller) still uses ancient gcc
> > (arm-none-eabi-gcc
> > > 4.7.2 from Yagarto), but I think it should still work.
> >
> > > I don't see too much of a problem if users need to open, fix and rebuild
> > > some old PLC projects with DT. If it's more than that, there will be
> > > complaints...
> >
> > As always the answer is 'It depends'. If during build process of user
> > PLC application the program is built complete from scratch, then it's ok.
> > But if matiec generated source code is linked against precompiled
> > library, that uses IEC_TIMESPEC, then it could be a problem. For
> > example, PLC_GetTime.
> >
> > Tomaz, do you use precompiled library to build PLC program?
> > Do you struct IEC_TIMESPEC in other places than PLC_GetTime?
> > Do you have any plans on solving 2038y issue?
> >
> >
> >
> > Guys,
> >
> > what do you think if the IEC_TIMESPEC structure will look like this:
> >
> > struct timespec {
> >  int32_t tv_sec;        /* seconds */
> >  int32_t tv_nsec;       /* nanoseconds */
> >  int32_t tv_sec_ext;    /* high word for seconds */
> > };
> >
> > In this case we have backward compatibility for old code, that access
> > structure using pointer. Do we have cases where IEC_TIMESPEC structure
> > is used as function argument by value?
> >
> >
> > > *Tomaz Orac*
> > > R&D SW manager, SMARTEH d.o.o.
> > >
> > > On 06. 06. 2017 16:31, Andrey Skvortsov wrote:
> > > > Hi Mario,
> > > >
> > > > On 17-06-04 23:48, [hidden email] wrote:
> > > > > >    Yes. I have no problem with changing the size of DT. Then
> > again, I am not
> > > > > > using this in an industrial setting. Maybe other people would have
> > a
> > > > > > problem?
> > > > Sure. Let's have a discussion first and only than make some such
> > changes.
> > > > I CC'd Eduard, Denis and Tomaz. Hopefully they have some feedback.
> > > > Guys, what do you think about this problem and currently suggested
> > solution?
> > > >
> > > > Actually everyone is welcome.
> > > >
> > > >
> > > > > struct timespec {
> > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > > > };
> > > > >
> > > > > What about dates earlier that 1970 in case of uint we will lost them!
> > > > > And how do we going to deal with substruction of time related types?
> > > > I agree with Paul, that tv_sec and tv_nsec should be signed types.
> > > >
> > > > type_initial_value.cc contains following comment:
> > > >
> > > >    /* FIXME: Our current implementation only allows dates from 1970
> > onwards,
> > > >     * but the standard defines the date 0001-01-01 as the default value
> > > >     * for the DATE data type. Untill we fix our implementation, we use
> > 1970-01-01
> > > >     * as our default value!!
> > > >     */
> > > >
> > > > with signed 64bit integer for tv_sec it's possible to represent
> > > > required by the standard initial value for DT and DATE types
> > > > (D#0001-01-01, section 2.3.3.2)
> > > >
> > > >
> > > >
> > > > > 2017-06-02 23:53 GMT+05:00 <[hidden email]>:
> > > > >
> > > > > > On Friday 02 June 2017 17:20:07 beremiz-devel@lists.
> > sourceforge.net wrote:
> > > > > > > Hi Mario,
> > > > > > >
> > > > > > > On 17-06-02 16:30, [hidden email] wrote:
> > > > > > > > On Friday 02 June 2017 08:03:53 beremiz-devel@lists.
> > sourceforge.net
> > > > > > wrote:
> > > > > > > > > Hi, Andrey!
> > > > > > > > >
> > > > > > > > > I think disabling locations for time related types is good
> > temporary
> > > > > > > > > solution.
> > > > > > > > >
> > > > > > > > > I also think that using uint64_t for timespec is HARD
> > decision:
> > > > > > > > >    - on one hand in may solve some problems in long term;
> > > > > > > >   I would be OK with this being a permanent solution.
> > > > > > > >
> > > > > > > >   Since the standard:
> > > > > > > >     - does not specify a size for the DT data type
> > > > > > > >
> > > > > > > >         (may be implementation specific)
> > > > > > > >
> > > > > > > >     - implicitly mandates that located variables should match
> > > > > > > >
> > > > > > > >         the size of the location
> > > > > > > if we are going to fix the problem (and I hope we are), then the
> > > > > > > question is do we *really* want to keep size of DT the same? If
> > we
> > > > > > > don't care about size of DT, then the easiest way would be just
> > to
> > > > > > > increase size of 'tv_sec' field to 'uint64_t'. This will keep
> > most
> > > > > > > parts of the existing matiec code the same. Some changes to
> > > > > > > iec_std_lib are needed, but they are easy and obvious.
> > > > > > >
> > > > > > > struct timespec {
> > > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > > >          long     tv_nsec;       /* nanoseconds */
> > > > > > > };
> > > > > > >
> > > > > > > 64-bit integer value for seconds is already used in:
> > > > > > > - OpenBSD/NetBSD;
> > > > > > > - x32 ABI for GNU/Linux (32-bit API on 64-bit systems);
> > > > > > > - all 64-bit GNU/Linux systems.
> > > > > > >
> > > > > > > There is ongoing work to add 64-bit seconds support to 32-bit
> > > > > > > GNU/Linux systems for all architectures. This will be added most
> > > > > > > likely through new syscall.
> > > > > > >
> > > > > >
> > > > > >   I like this method. As you say, with any luck matiec itself
> > would not
> > > > > > need to
> > > > > > change at all. I would actually suggest, if we are going to change
> > this, to
> > > > > > change the tv_nsec too, so we can have a fixed sized of DT.
> > > > Some small changes will be necessary, because iec_std_lib.h contains a
> > > > lot of typecastings to 'long int'. This has to be fixed.
> > > >
> > > >
> > > > > > struct timespec {
> > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > > > };
> > > > > >
> > > > > >
> > >
> >
> > > ------------------------------------------------------------
> > ------------------
> > > 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] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
Hi, Andrey!

As our product line is not on market yet, we can change sizes with no complain :) But others do not have such option :(

My opinion is "the propper solution must not affect existing matiec-related products, no exceptions."

Yes, I'm coservative :)

All newcomers will use default values, that would generate
problematic code and then later people will probably complain about
bad code generated by matiec.

We should document this issue properly, IMO this will address the problem with newcomers.

IMHO this trick will work only if we change default values to int64_t
*now*. And people who cares about backward compatibility
can set IEC_SEC_T to int32_t by defines at compile time.

Default values are the minor issue the major ones are changes in iec_std_lib and stage3-4 changes (do we need them?).

Translator code must be "decoupled" from iec_std_lib to make compiletime type handling...

Best regards,
Paul Beltyukov


2017-06-13 11:58 GMT+05:00 <[hidden email]>:
On 17-06-13 11:06, [hidden email] wrote:
> Hi, Andrey!
>
> How about:
>
>
> > #ifndef IEC_SEC_T
> > #define IEC_SEC_T long int
> > #endif
> >
> > #ifndef IEC_NSEC_T
> > #define IEC_NSEC_T long int
> > #endif
>
>
> >
> typedef struct {
> >     IEC_SEC_T   tv_sec;            /* Seconds.  */
> >     IEC_NSEC_T tv_nsec;           /* Nanoseconds.  */
> > } /* __attribute__((packed)) */ IEC_TIMESPEC;  /* packed is gcc specific!
> > */
> >
>
> In such case we have current implementation by default, and if we want to
> solve 2048 problem on new devices,
> then we have to add -DIEC_SEC_T=int64_t -DIEC_NSEC_T=int32_t options when
> bilding C-code.

It is obvious solution, but the problem is here. Some questions
are still open.
When we change the default size of IEC_SEC_T and IEC_NSEC_T to int64_t?
All newcomers will use default values, that would generate
problematic code and then later people will probably complain about
bad code generated by matiec.

IMHO this trick will work only if we change default values to int64_t
*now*. And people who cares about backward compatibility
can set IEC_SEC_T to int32_t by defines at compile time.


Paul, could you please say your opinion on my last suggested approach?

> 2017-06-09 15:22 GMT+05:00 <[hidden email]>:
>
> > On 17-06-07 15:49, [hidden email] wrote:
> > > Hi!
> > >
> > > We don't really use DT much, it's usually more about counters, etc., but
> > > this is going to change on the new controller (schedules are used a
> > > lot).
> >
> > Hi Tomaz,
> >
> > thank you for the answer. Not only DT is affected, but DATE, TIME and
> > TOD types. Because all these types are the same struct IEC_TIMESPEC
> > internally.
> >
> > You say you don't use DT, but you probably use timers (TON, TOF, TP).
> > They use TIME and therefore rely on IEC_TIMESPEC.
> >
> >
> >
> > > The old one (MC8, microcontroller) still uses ancient gcc
> > (arm-none-eabi-gcc
> > > 4.7.2 from Yagarto), but I think it should still work.
> >
> > > I don't see too much of a problem if users need to open, fix and rebuild
> > > some old PLC projects with DT. If it's more than that, there will be
> > > complaints...
> >
> > As always the answer is 'It depends'. If during build process of user
> > PLC application the program is built complete from scratch, then it's ok.
> > But if matiec generated source code is linked against precompiled
> > library, that uses IEC_TIMESPEC, then it could be a problem. For
> > example, PLC_GetTime.
> >
> > Tomaz, do you use precompiled library to build PLC program?
> > Do you struct IEC_TIMESPEC in other places than PLC_GetTime?
> > Do you have any plans on solving 2038y issue?
> >
> >
> >
> > Guys,
> >
> > what do you think if the IEC_TIMESPEC structure will look like this:
> >
> > struct timespec {
> >  int32_t tv_sec;        /* seconds */
> >  int32_t tv_nsec;       /* nanoseconds */
> >  int32_t tv_sec_ext;    /* high word for seconds */
> > };
> >
> > In this case we have backward compatibility for old code, that access
> > structure using pointer. Do we have cases where IEC_TIMESPEC structure
> > is used as function argument by value?
> >
> >
> > > *Tomaz Orac*
> > > R&D SW manager, SMARTEH d.o.o.
> > >
> > > On 06. 06. 2017 16:31, Andrey Skvortsov wrote:
> > > > Hi Mario,
> > > >
> > > > On 17-06-04 23:48, [hidden email] wrote:
> > > > > >    Yes. I have no problem with changing the size of DT. Then
> > again, I am not
> > > > > > using this in an industrial setting. Maybe other people would have
> > a
> > > > > > problem?
> > > > Sure. Let's have a discussion first and only than make some such
> > changes.
> > > > I CC'd Eduard, Denis and Tomaz. Hopefully they have some feedback.
> > > > Guys, what do you think about this problem and currently suggested
> > solution?
> > > >
> > > > Actually everyone is welcome.
> > > >
> > > >
> > > > > struct timespec {
> > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > > > };
> > > > >
> > > > > What about dates earlier that 1970 in case of uint we will lost them!
> > > > > And how do we going to deal with substruction of time related types?
> > > > I agree with Paul, that tv_sec and tv_nsec should be signed types.
> > > >
> > > > type_initial_value.cc contains following comment:
> > > >
> > > >    /* FIXME: Our current implementation only allows dates from 1970
> > onwards,
> > > >     * but the standard defines the date 0001-01-01 as the default value
> > > >     * for the DATE data type. Untill we fix our implementation, we use
> > 1970-01-01
> > > >     * as our default value!!
> > > >     */
> > > >
> > > > with signed 64bit integer for tv_sec it's possible to represent
> > > > required by the standard initial value for DT and DATE types
> > > > (D#0001-01-01, section 2.3.3.2)
> > > >
> > > >
> > > >
> > > > > 2017-06-02 23:53 GMT+05:00 <[hidden email]>:
> > > > >
> > > > > > On Friday 02 June 2017 17:20:07 beremiz-devel@lists.
> > sourceforge.net wrote:
> > > > > > > Hi Mario,
> > > > > > >
> > > > > > > On 17-06-02 16:30, [hidden email] wrote:
> > > > > > > > On Friday 02 June 2017 08:03:53 beremiz-devel@lists.
> > sourceforge.net
> > > > > > wrote:
> > > > > > > > > Hi, Andrey!
> > > > > > > > >
> > > > > > > > > I think disabling locations for time related types is good
> > temporary
> > > > > > > > > solution.
> > > > > > > > >
> > > > > > > > > I also think that using uint64_t for timespec is HARD
> > decision:
> > > > > > > > >    - on one hand in may solve some problems in long term;
> > > > > > > >   I would be OK with this being a permanent solution.
> > > > > > > >
> > > > > > > >   Since the standard:
> > > > > > > >     - does not specify a size for the DT data type
> > > > > > > >
> > > > > > > >         (may be implementation specific)
> > > > > > > >
> > > > > > > >     - implicitly mandates that located variables should match
> > > > > > > >
> > > > > > > >         the size of the location
> > > > > > > if we are going to fix the problem (and I hope we are), then the
> > > > > > > question is do we *really* want to keep size of DT the same? If
> > we
> > > > > > > don't care about size of DT, then the easiest way would be just
> > to
> > > > > > > increase size of 'tv_sec' field to 'uint64_t'. This will keep
> > most
> > > > > > > parts of the existing matiec code the same. Some changes to
> > > > > > > iec_std_lib are needed, but they are easy and obvious.
> > > > > > >
> > > > > > > struct timespec {
> > > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > > >          long     tv_nsec;       /* nanoseconds */
> > > > > > > };
> > > > > > >
> > > > > > > 64-bit integer value for seconds is already used in:
> > > > > > > - OpenBSD/NetBSD;
> > > > > > > - x32 ABI for GNU/Linux (32-bit API on 64-bit systems);
> > > > > > > - all 64-bit GNU/Linux systems.
> > > > > > >
> > > > > > > There is ongoing work to add 64-bit seconds support to 32-bit
> > > > > > > GNU/Linux systems for all architectures. This will be added most
> > > > > > > likely through new syscall.
> > > > > > >
> > > > > >
> > > > > >   I like this method. As you say, with any luck matiec itself
> > would not
> > > > > > need to
> > > > > > change at all. I would actually suggest, if we are going to change
> > this, to
> > > > > > change the tv_nsec too, so we can have a fixed sized of DT.
> > > > Some small changes will be necessary, because iec_std_lib.h contains a
> > > > lot of typecastings to 'long int'. This has to be fixed.
> > > >
> > > >
> > > > > > struct timespec {
> > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > > > };
> > > > > >
> > > > > >
> > >
> >
> > > ------------------------------------------------------------
> > ------------------
> > > 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] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
On 17-06-13 12:20, [hidden email] wrote:
> Hi, Andrey!
>
> As our product line is not on market yet, we can change sizes with no
> complain :) But others do not have such option :(
Same here. I don't have any problem with changing size of DT.
Therefore I'd like to hear their opinion and hopefully suggested solution.

> My opinion is "the propper solution must not affect existing matiec-related
> products, no exceptions."
>
> Yes, I'm coservative :)

I agree with you about conservative approach.
Have you looked at my last suggested solution about adding
  int32_t tv_sec_ext;    /* high word for seconds */
to the IEC_TIMESPEC structure?
Any comments? Answers on questions?


> > All newcomers will use default values, that would generate
> > problematic code and then later people will probably complain about
> > bad code generated by matiec.
>
>
> We should document this issue properly, IMO this will address the problem
> with newcomers.

Seriously? I see people don't even read README file for matiec to get
build instructions.

> IMHO this trick will work only if we change default values to int64_t
> > *now*. And people who cares about backward compatibility
> > can set IEC_SEC_T to int32_t by defines at compile time.
>
>
> Default values are the minor issue the major ones are changes in
> iec_std_lib and
If we just change the size of tv_sec, then changes in iec_std_lib are
trivial, mostly only fixing typecasing. But anyway changes in iec_std_lib
doesn't cause backward compatibility issue. This is not a problem here.


> stage3-4 changes (do we need them?).
>
> Translator code must be "decoupled" from iec_std_lib to make compiletime
> type handling...
Could you please point to the code in stage3/stage4 that relies on
internal DT details?

>
> 2017-06-13 11:58 GMT+05:00 <[hidden email]>:
>
> > On 17-06-13 11:06, [hidden email] wrote:
> > > Hi, Andrey!
> > >
> > > How about:
> > >
> > >
> > > > #ifndef IEC_SEC_T
> > > > #define IEC_SEC_T long int
> > > > #endif
> > > >
> > > > #ifndef IEC_NSEC_T
> > > > #define IEC_NSEC_T long int
> > > > #endif
> > >
> > >
> > > >
> > > typedef struct {
> > > >     IEC_SEC_T   tv_sec;            /* Seconds.  */
> > > >     IEC_NSEC_T tv_nsec;           /* Nanoseconds.  */
> > > > } /* __attribute__((packed)) */ IEC_TIMESPEC;  /* packed is gcc
> > specific!
> > > > */
> > > >
> > >
> > > In such case we have current implementation by default, and if we want to
> > > solve 2048 problem on new devices,
> > > then we have to add -DIEC_SEC_T=int64_t -DIEC_NSEC_T=int32_t options when
> > > bilding C-code.
> >
> > It is obvious solution, but the problem is here. Some questions
> > are still open.
> > When we change the default size of IEC_SEC_T and IEC_NSEC_T to int64_t?
> > All newcomers will use default values, that would generate
> > problematic code and then later people will probably complain about
> > bad code generated by matiec.
> >
> > IMHO this trick will work only if we change default values to int64_t
> > *now*. And people who cares about backward compatibility
> > can set IEC_SEC_T to int32_t by defines at compile time.
> >
> >
> > Paul, could you please say your opinion on my last suggested approach?
> >
> > > 2017-06-09 15:22 GMT+05:00 <[hidden email]>:
> > >
> > > > On 17-06-07 15:49, [hidden email] wrote:
> > > > > Hi!
> > > > >
> > > > > We don't really use DT much, it's usually more about counters, etc.,
> > but
> > > > > this is going to change on the new controller (schedules are used a
> > > > > lot).
> > > >
> > > > Hi Tomaz,
> > > >
> > > > thank you for the answer. Not only DT is affected, but DATE, TIME and
> > > > TOD types. Because all these types are the same struct IEC_TIMESPEC
> > > > internally.
> > > >
> > > > You say you don't use DT, but you probably use timers (TON, TOF, TP).
> > > > They use TIME and therefore rely on IEC_TIMESPEC.
> > > >
> > > >
> > > >
> > > > > The old one (MC8, microcontroller) still uses ancient gcc
> > > > (arm-none-eabi-gcc
> > > > > 4.7.2 from Yagarto), but I think it should still work.
> > > >
> > > > > I don't see too much of a problem if users need to open, fix and
> > rebuild
> > > > > some old PLC projects with DT. If it's more than that, there will be
> > > > > complaints...
> > > >
> > > > As always the answer is 'It depends'. If during build process of user
> > > > PLC application the program is built complete from scratch, then it's
> > ok.
> > > > But if matiec generated source code is linked against precompiled
> > > > library, that uses IEC_TIMESPEC, then it could be a problem. For
> > > > example, PLC_GetTime.
> > > >
> > > > Tomaz, do you use precompiled library to build PLC program?
> > > > Do you struct IEC_TIMESPEC in other places than PLC_GetTime?
> > > > Do you have any plans on solving 2038y issue?
> > > >
> > > >
> > > >
> > > > Guys,
> > > >
> > > > what do you think if the IEC_TIMESPEC structure will look like this:
> > > >
> > > > struct timespec {
> > > >  int32_t tv_sec;        /* seconds */
> > > >  int32_t tv_nsec;       /* nanoseconds */
> > > >  int32_t tv_sec_ext;    /* high word for seconds */
> > > > };
> > > >
> > > > In this case we have backward compatibility for old code, that access
> > > > structure using pointer. Do we have cases where IEC_TIMESPEC structure
> > > > is used as function argument by value?
> > > >
> > > >
> > > > > *Tomaz Orac*
> > > > > R&D SW manager, SMARTEH d.o.o.
> > > > >
> > > > > On 06. 06. 2017 16:31, Andrey Skvortsov wrote:
> > > > > > Hi Mario,
> > > > > >
> > > > > > On 17-06-04 23:48, [hidden email] wrote:
> > > > > > > >    Yes. I have no problem with changing the size of DT. Then
> > > > again, I am not
> > > > > > > > using this in an industrial setting. Maybe other people would
> > have
> > > > a
> > > > > > > > problem?
> > > > > > Sure. Let's have a discussion first and only than make some such
> > > > changes.
> > > > > > I CC'd Eduard, Denis and Tomaz. Hopefully they have some feedback.
> > > > > > Guys, what do you think about this problem and currently suggested
> > > > solution?
> > > > > >
> > > > > > Actually everyone is welcome.
> > > > > >
> > > > > >
> > > > > > > struct timespec {
> > > > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > > > > > };
> > > > > > >
> > > > > > > What about dates earlier that 1970 in case of uint we will lost
> > them!
> > > > > > > And how do we going to deal with substruction of time related
> > types?
> > > > > > I agree with Paul, that tv_sec and tv_nsec should be signed types.
> > > > > >
> > > > > > type_initial_value.cc contains following comment:
> > > > > >
> > > > > >    /* FIXME: Our current implementation only allows dates from 1970
> > > > onwards,
> > > > > >     * but the standard defines the date 0001-01-01 as the default
> > value
> > > > > >     * for the DATE data type. Untill we fix our implementation, we
> > use
> > > > 1970-01-01
> > > > > >     * as our default value!!
> > > > > >     */
> > > > > >
> > > > > > with signed 64bit integer for tv_sec it's possible to represent
> > > > > > required by the standard initial value for DT and DATE types
> > > > > > (D#0001-01-01, section 2.3.3.2)
> > > > > >
> > > > > >
> > > > > >
> > > > > > > 2017-06-02 23:53 GMT+05:00 <[hidden email]
> > >:
> > > > > > >
> > > > > > > > On Friday 02 June 2017 17:20:07 beremiz-devel@lists.
> > > > sourceforge.net wrote:
> > > > > > > > > Hi Mario,
> > > > > > > > >
> > > > > > > > > On 17-06-02 16:30, [hidden email]
> > wrote:
> > > > > > > > > > On Friday 02 June 2017 08:03:53 beremiz-devel@lists.
> > > > sourceforge.net
> > > > > > > > wrote:
> > > > > > > > > > > Hi, Andrey!
> > > > > > > > > > >
> > > > > > > > > > > I think disabling locations for time related types is
> > good
> > > > temporary
> > > > > > > > > > > solution.
> > > > > > > > > > >
> > > > > > > > > > > I also think that using uint64_t for timespec is HARD
> > > > decision:
> > > > > > > > > > >    - on one hand in may solve some problems in long term;
> > > > > > > > > >   I would be OK with this being a permanent solution.
> > > > > > > > > >
> > > > > > > > > >   Since the standard:
> > > > > > > > > >     - does not specify a size for the DT data type
> > > > > > > > > >
> > > > > > > > > >         (may be implementation specific)
> > > > > > > > > >
> > > > > > > > > >     - implicitly mandates that located variables should
> > match
> > > > > > > > > >
> > > > > > > > > >         the size of the location
> > > > > > > > > if we are going to fix the problem (and I hope we are), then
> > the
> > > > > > > > > question is do we *really* want to keep size of DT the same?
> > If
> > > > we
> > > > > > > > > don't care about size of DT, then the easiest way would be
> > just
> > > > to
> > > > > > > > > increase size of 'tv_sec' field to 'uint64_t'. This will keep
> > > > most
> > > > > > > > > parts of the existing matiec code the same. Some changes to
> > > > > > > > > iec_std_lib are needed, but they are easy and obvious.
> > > > > > > > >
> > > > > > > > > struct timespec {
> > > > > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > > > > >          long     tv_nsec;       /* nanoseconds */
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > 64-bit integer value for seconds is already used in:
> > > > > > > > > - OpenBSD/NetBSD;
> > > > > > > > > - x32 ABI for GNU/Linux (32-bit API on 64-bit systems);
> > > > > > > > > - all 64-bit GNU/Linux systems.
> > > > > > > > >
> > > > > > > > > There is ongoing work to add 64-bit seconds support to 32-bit
> > > > > > > > > GNU/Linux systems for all architectures. This will be added
> > most
> > > > > > > > > likely through new syscall.
> > > > > > > > >
> > > > > > > >
> > > > > > > >   I like this method. As you say, with any luck matiec itself
> > > > would not
> > > > > > > > need to
> > > > > > > > change at all. I would actually suggest, if we are going to
> > change
> > > > this, to
> > > > > > > > change the tv_nsec too, so we can have a fixed sized of DT.
> > > > > > Some small changes will be necessary, because iec_std_lib.h
> > contains a
> > > > > > lot of typecastings to 'long int'. This has to be fixed.
> > > > > >
> > > > > >
> > > > > > > > struct timespec {
> > > > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > > > > > };
> > > > > > > >
> > > > > > > >
> > > > >
> > > >
> > > > > ------------------------------------------------------------
> > > > ------------------
> > > > > 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] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
Hi, Andrey!

Have you looked at my last suggested solution about adding
  int32_t tv_sec_ext;    /* high word for seconds */
to the IEC_TIMESPEC structure?
Any comments? Answers on questions?

Yes, I've looked at it.

There may be an issue if older runtime has some DT var and newer code calls some dt-related function on such variable. We could get out of bounds access in such case...

And yes, stdlib changes are not so trivial in case of tv_sec_ext...


Could you please point to the code in stage3/stage4 that relies on
internal DT details?

I've searched the code for _dt_, _timespec_, _time_, etc, and for tv_sec, tv_nsec.

It looks like there are no direct timespec internals access in the translator code and we can just change std lib.

So, I think no changes in translator needed, may be Mario can point to some "weak" places...

Best regards,
Paul Beltyukov

2017-06-13 13:02 GMT+05:00 <[hidden email]>:
On 17-06-13 12:20, [hidden email] wrote:
> Hi, Andrey!
>
> As our product line is not on market yet, we can change sizes with no
> complain :) But others do not have such option :(
Same here. I don't have any problem with changing size of DT.
Therefore I'd like to hear their opinion and hopefully suggested solution.

> My opinion is "the propper solution must not affect existing matiec-related
> products, no exceptions."
>
> Yes, I'm coservative :)

I agree with you about conservative approach.
Have you looked at my last suggested solution about adding
  int32_t tv_sec_ext;    /* high word for seconds */
to the IEC_TIMESPEC structure?
Any comments? Answers on questions?


> > All newcomers will use default values, that would generate
> > problematic code and then later people will probably complain about
> > bad code generated by matiec.
>
>
> We should document this issue properly, IMO this will address the problem
> with newcomers.

Seriously? I see people don't even read README file for matiec to get
build instructions.

> IMHO this trick will work only if we change default values to int64_t
> > *now*. And people who cares about backward compatibility
> > can set IEC_SEC_T to int32_t by defines at compile time.
>
>
> Default values are the minor issue the major ones are changes in
> iec_std_lib and
If we just change the size of tv_sec, then changes in iec_std_lib are
trivial, mostly only fixing typecasing. But anyway changes in iec_std_lib
doesn't cause backward compatibility issue. This is not a problem here.


> stage3-4 changes (do we need them?).
>
> Translator code must be "decoupled" from iec_std_lib to make compiletime
> type handling...
Could you please point to the code in stage3/stage4 that relies on
internal DT details?

>
> 2017-06-13 11:58 GMT+05:00 <[hidden email]>:
>
> > On 17-06-13 11:06, [hidden email] wrote:
> > > Hi, Andrey!
> > >
> > > How about:
> > >
> > >
> > > > #ifndef IEC_SEC_T
> > > > #define IEC_SEC_T long int
> > > > #endif
> > > >
> > > > #ifndef IEC_NSEC_T
> > > > #define IEC_NSEC_T long int
> > > > #endif
> > >
> > >
> > > >
> > > typedef struct {
> > > >     IEC_SEC_T   tv_sec;            /* Seconds.  */
> > > >     IEC_NSEC_T tv_nsec;           /* Nanoseconds.  */
> > > > } /* __attribute__((packed)) */ IEC_TIMESPEC;  /* packed is gcc
> > specific!
> > > > */
> > > >
> > >
> > > In such case we have current implementation by default, and if we want to
> > > solve 2048 problem on new devices,
> > > then we have to add -DIEC_SEC_T=int64_t -DIEC_NSEC_T=int32_t options when
> > > bilding C-code.
> >
> > It is obvious solution, but the problem is here. Some questions
> > are still open.
> > When we change the default size of IEC_SEC_T and IEC_NSEC_T to int64_t?
> > All newcomers will use default values, that would generate
> > problematic code and then later people will probably complain about
> > bad code generated by matiec.
> >
> > IMHO this trick will work only if we change default values to int64_t
> > *now*. And people who cares about backward compatibility
> > can set IEC_SEC_T to int32_t by defines at compile time.
> >
> >
> > Paul, could you please say your opinion on my last suggested approach?
> >
> > > 2017-06-09 15:22 GMT+05:00 <[hidden email]>:
> > >
> > > > On 17-06-07 15:49, [hidden email] wrote:
> > > > > Hi!
> > > > >
> > > > > We don't really use DT much, it's usually more about counters, etc.,
> > but
> > > > > this is going to change on the new controller (schedules are used a
> > > > > lot).
> > > >
> > > > Hi Tomaz,
> > > >
> > > > thank you for the answer. Not only DT is affected, but DATE, TIME and
> > > > TOD types. Because all these types are the same struct IEC_TIMESPEC
> > > > internally.
> > > >
> > > > You say you don't use DT, but you probably use timers (TON, TOF, TP).
> > > > They use TIME and therefore rely on IEC_TIMESPEC.
> > > >
> > > >
> > > >
> > > > > The old one (MC8, microcontroller) still uses ancient gcc
> > > > (arm-none-eabi-gcc
> > > > > 4.7.2 from Yagarto), but I think it should still work.
> > > >
> > > > > I don't see too much of a problem if users need to open, fix and
> > rebuild
> > > > > some old PLC projects with DT. If it's more than that, there will be
> > > > > complaints...
> > > >
> > > > As always the answer is 'It depends'. If during build process of user
> > > > PLC application the program is built complete from scratch, then it's
> > ok.
> > > > But if matiec generated source code is linked against precompiled
> > > > library, that uses IEC_TIMESPEC, then it could be a problem. For
> > > > example, PLC_GetTime.
> > > >
> > > > Tomaz, do you use precompiled library to build PLC program?
> > > > Do you struct IEC_TIMESPEC in other places than PLC_GetTime?
> > > > Do you have any plans on solving 2038y issue?
> > > >
> > > >
> > > >
> > > > Guys,
> > > >
> > > > what do you think if the IEC_TIMESPEC structure will look like this:
> > > >
> > > > struct timespec {
> > > >  int32_t tv_sec;        /* seconds */
> > > >  int32_t tv_nsec;       /* nanoseconds */
> > > >  int32_t tv_sec_ext;    /* high word for seconds */
> > > > };
> > > >
> > > > In this case we have backward compatibility for old code, that access
> > > > structure using pointer. Do we have cases where IEC_TIMESPEC structure
> > > > is used as function argument by value?
> > > >
> > > >
> > > > > *Tomaz Orac*
> > > > > R&D SW manager, SMARTEH d.o.o.
> > > > >
> > > > > On 06. 06. 2017 16:31, Andrey Skvortsov wrote:
> > > > > > Hi Mario,
> > > > > >
> > > > > > On 17-06-04 23:48, [hidden email] wrote:
> > > > > > > >    Yes. I have no problem with changing the size of DT. Then
> > > > again, I am not
> > > > > > > > using this in an industrial setting. Maybe other people would
> > have
> > > > a
> > > > > > > > problem?
> > > > > > Sure. Let's have a discussion first and only than make some such
> > > > changes.
> > > > > > I CC'd Eduard, Denis and Tomaz. Hopefully they have some feedback.
> > > > > > Guys, what do you think about this problem and currently suggested
> > > > solution?
> > > > > >
> > > > > > Actually everyone is welcome.
> > > > > >
> > > > > >
> > > > > > > struct timespec {
> > > > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > > > > > };
> > > > > > >
> > > > > > > What about dates earlier that 1970 in case of uint we will lost
> > them!
> > > > > > > And how do we going to deal with substruction of time related
> > types?
> > > > > > I agree with Paul, that tv_sec and tv_nsec should be signed types.
> > > > > >
> > > > > > type_initial_value.cc contains following comment:
> > > > > >
> > > > > >    /* FIXME: Our current implementation only allows dates from 1970
> > > > onwards,
> > > > > >     * but the standard defines the date 0001-01-01 as the default
> > value
> > > > > >     * for the DATE data type. Untill we fix our implementation, we
> > use
> > > > 1970-01-01
> > > > > >     * as our default value!!
> > > > > >     */
> > > > > >
> > > > > > with signed 64bit integer for tv_sec it's possible to represent
> > > > > > required by the standard initial value for DT and DATE types
> > > > > > (D#0001-01-01, section 2.3.3.2)
> > > > > >
> > > > > >
> > > > > >
> > > > > > > 2017-06-02 23:53 GMT+05:00 <[hidden email]
> > >:
> > > > > > >
> > > > > > > > On Friday 02 June 2017 17:20:07 beremiz-devel@lists.
> > > > sourceforge.net wrote:
> > > > > > > > > Hi Mario,
> > > > > > > > >
> > > > > > > > > On 17-06-02 16:30, [hidden email]
> > wrote:
> > > > > > > > > > On Friday 02 June 2017 08:03:53 beremiz-devel@lists.
> > > > sourceforge.net
> > > > > > > > wrote:
> > > > > > > > > > > Hi, Andrey!
> > > > > > > > > > >
> > > > > > > > > > > I think disabling locations for time related types is
> > good
> > > > temporary
> > > > > > > > > > > solution.
> > > > > > > > > > >
> > > > > > > > > > > I also think that using uint64_t for timespec is HARD
> > > > decision:
> > > > > > > > > > >    - on one hand in may solve some problems in long term;
> > > > > > > > > >   I would be OK with this being a permanent solution.
> > > > > > > > > >
> > > > > > > > > >   Since the standard:
> > > > > > > > > >     - does not specify a size for the DT data type
> > > > > > > > > >
> > > > > > > > > >         (may be implementation specific)
> > > > > > > > > >
> > > > > > > > > >     - implicitly mandates that located variables should
> > match
> > > > > > > > > >
> > > > > > > > > >         the size of the location
> > > > > > > > > if we are going to fix the problem (and I hope we are), then
> > the
> > > > > > > > > question is do we *really* want to keep size of DT the same?
> > If
> > > > we
> > > > > > > > > don't care about size of DT, then the easiest way would be
> > just
> > > > to
> > > > > > > > > increase size of 'tv_sec' field to 'uint64_t'. This will keep
> > > > most
> > > > > > > > > parts of the existing matiec code the same. Some changes to
> > > > > > > > > iec_std_lib are needed, but they are easy and obvious.
> > > > > > > > >
> > > > > > > > > struct timespec {
> > > > > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > > > > >          long     tv_nsec;       /* nanoseconds */
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > 64-bit integer value for seconds is already used in:
> > > > > > > > > - OpenBSD/NetBSD;
> > > > > > > > > - x32 ABI for GNU/Linux (32-bit API on 64-bit systems);
> > > > > > > > > - all 64-bit GNU/Linux systems.
> > > > > > > > >
> > > > > > > > > There is ongoing work to add 64-bit seconds support to 32-bit
> > > > > > > > > GNU/Linux systems for all architectures. This will be added
> > most
> > > > > > > > > likely through new syscall.
> > > > > > > > >
> > > > > > > >
> > > > > > > >   I like this method. As you say, with any luck matiec itself
> > > > would not
> > > > > > > > need to
> > > > > > > > change at all. I would actually suggest, if we are going to
> > change
> > > > this, to
> > > > > > > > change the tv_nsec too, so we can have a fixed sized of DT.
> > > > > > Some small changes will be necessary, because iec_std_lib.h
> > contains a
> > > > > > lot of typecastings to 'long int'. This has to be fixed.
> > > > > >
> > > > > >
> > > > > > > > struct timespec {
> > > > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > > > > > };
> > > > > > > >
> > > > > > > >
> > > > >
> > > >
> > > > > ------------------------------------------------------------
> > > > ------------------
> > > > > 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



------------------------------------------------------------------------------
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] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
Seriously? I see people don't even read README file for matiec to get
build instructions.

It's realy sad but true. IMO the best we can do is to add some FAQ and troubleshooting section to readme/docs.

Best regards,
Paul Beltyukov

2017-06-13 13:02 GMT+05:00 <[hidden email]>:
On 17-06-13 12:20, [hidden email] wrote:
> Hi, Andrey!
>
> As our product line is not on market yet, we can change sizes with no
> complain :) But others do not have such option :(
Same here. I don't have any problem with changing size of DT.
Therefore I'd like to hear their opinion and hopefully suggested solution.

> My opinion is "the propper solution must not affect existing matiec-related
> products, no exceptions."
>
> Yes, I'm coservative :)

I agree with you about conservative approach.
Have you looked at my last suggested solution about adding
  int32_t tv_sec_ext;    /* high word for seconds */
to the IEC_TIMESPEC structure?
Any comments? Answers on questions?


> > All newcomers will use default values, that would generate
> > problematic code and then later people will probably complain about
> > bad code generated by matiec.
>
>
> We should document this issue properly, IMO this will address the problem
> with newcomers.

Seriously? I see people don't even read README file for matiec to get
build instructions.

> IMHO this trick will work only if we change default values to int64_t
> > *now*. And people who cares about backward compatibility
> > can set IEC_SEC_T to int32_t by defines at compile time.
>
>
> Default values are the minor issue the major ones are changes in
> iec_std_lib and
If we just change the size of tv_sec, then changes in iec_std_lib are
trivial, mostly only fixing typecasing. But anyway changes in iec_std_lib
doesn't cause backward compatibility issue. This is not a problem here.


> stage3-4 changes (do we need them?).
>
> Translator code must be "decoupled" from iec_std_lib to make compiletime
> type handling...
Could you please point to the code in stage3/stage4 that relies on
internal DT details?

>
> 2017-06-13 11:58 GMT+05:00 <[hidden email]>:
>
> > On 17-06-13 11:06, [hidden email] wrote:
> > > Hi, Andrey!
> > >
> > > How about:
> > >
> > >
> > > > #ifndef IEC_SEC_T
> > > > #define IEC_SEC_T long int
> > > > #endif
> > > >
> > > > #ifndef IEC_NSEC_T
> > > > #define IEC_NSEC_T long int
> > > > #endif
> > >
> > >
> > > >
> > > typedef struct {
> > > >     IEC_SEC_T   tv_sec;            /* Seconds.  */
> > > >     IEC_NSEC_T tv_nsec;           /* Nanoseconds.  */
> > > > } /* __attribute__((packed)) */ IEC_TIMESPEC;  /* packed is gcc
> > specific!
> > > > */
> > > >
> > >
> > > In such case we have current implementation by default, and if we want to
> > > solve 2048 problem on new devices,
> > > then we have to add -DIEC_SEC_T=int64_t -DIEC_NSEC_T=int32_t options when
> > > bilding C-code.
> >
> > It is obvious solution, but the problem is here. Some questions
> > are still open.
> > When we change the default size of IEC_SEC_T and IEC_NSEC_T to int64_t?
> > All newcomers will use default values, that would generate
> > problematic code and then later people will probably complain about
> > bad code generated by matiec.
> >
> > IMHO this trick will work only if we change default values to int64_t
> > *now*. And people who cares about backward compatibility
> > can set IEC_SEC_T to int32_t by defines at compile time.
> >
> >
> > Paul, could you please say your opinion on my last suggested approach?
> >
> > > 2017-06-09 15:22 GMT+05:00 <[hidden email]>:
> > >
> > > > On 17-06-07 15:49, [hidden email] wrote:
> > > > > Hi!
> > > > >
> > > > > We don't really use DT much, it's usually more about counters, etc.,
> > but
> > > > > this is going to change on the new controller (schedules are used a
> > > > > lot).
> > > >
> > > > Hi Tomaz,
> > > >
> > > > thank you for the answer. Not only DT is affected, but DATE, TIME and
> > > > TOD types. Because all these types are the same struct IEC_TIMESPEC
> > > > internally.
> > > >
> > > > You say you don't use DT, but you probably use timers (TON, TOF, TP).
> > > > They use TIME and therefore rely on IEC_TIMESPEC.
> > > >
> > > >
> > > >
> > > > > The old one (MC8, microcontroller) still uses ancient gcc
> > > > (arm-none-eabi-gcc
> > > > > 4.7.2 from Yagarto), but I think it should still work.
> > > >
> > > > > I don't see too much of a problem if users need to open, fix and
> > rebuild
> > > > > some old PLC projects with DT. If it's more than that, there will be
> > > > > complaints...
> > > >
> > > > As always the answer is 'It depends'. If during build process of user
> > > > PLC application the program is built complete from scratch, then it's
> > ok.
> > > > But if matiec generated source code is linked against precompiled
> > > > library, that uses IEC_TIMESPEC, then it could be a problem. For
> > > > example, PLC_GetTime.
> > > >
> > > > Tomaz, do you use precompiled library to build PLC program?
> > > > Do you struct IEC_TIMESPEC in other places than PLC_GetTime?
> > > > Do you have any plans on solving 2038y issue?
> > > >
> > > >
> > > >
> > > > Guys,
> > > >
> > > > what do you think if the IEC_TIMESPEC structure will look like this:
> > > >
> > > > struct timespec {
> > > >  int32_t tv_sec;        /* seconds */
> > > >  int32_t tv_nsec;       /* nanoseconds */
> > > >  int32_t tv_sec_ext;    /* high word for seconds */
> > > > };
> > > >
> > > > In this case we have backward compatibility for old code, that access
> > > > structure using pointer. Do we have cases where IEC_TIMESPEC structure
> > > > is used as function argument by value?
> > > >
> > > >
> > > > > *Tomaz Orac*
> > > > > R&D SW manager, SMARTEH d.o.o.
> > > > >
> > > > > On 06. 06. 2017 16:31, Andrey Skvortsov wrote:
> > > > > > Hi Mario,
> > > > > >
> > > > > > On 17-06-04 23:48, [hidden email] wrote:
> > > > > > > >    Yes. I have no problem with changing the size of DT. Then
> > > > again, I am not
> > > > > > > > using this in an industrial setting. Maybe other people would
> > have
> > > > a
> > > > > > > > problem?
> > > > > > Sure. Let's have a discussion first and only than make some such
> > > > changes.
> > > > > > I CC'd Eduard, Denis and Tomaz. Hopefully they have some feedback.
> > > > > > Guys, what do you think about this problem and currently suggested
> > > > solution?
> > > > > >
> > > > > > Actually everyone is welcome.
> > > > > >
> > > > > >
> > > > > > > struct timespec {
> > > > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > > > > > };
> > > > > > >
> > > > > > > What about dates earlier that 1970 in case of uint we will lost
> > them!
> > > > > > > And how do we going to deal with substruction of time related
> > types?
> > > > > > I agree with Paul, that tv_sec and tv_nsec should be signed types.
> > > > > >
> > > > > > type_initial_value.cc contains following comment:
> > > > > >
> > > > > >    /* FIXME: Our current implementation only allows dates from 1970
> > > > onwards,
> > > > > >     * but the standard defines the date 0001-01-01 as the default
> > value
> > > > > >     * for the DATE data type. Untill we fix our implementation, we
> > use
> > > > 1970-01-01
> > > > > >     * as our default value!!
> > > > > >     */
> > > > > >
> > > > > > with signed 64bit integer for tv_sec it's possible to represent
> > > > > > required by the standard initial value for DT and DATE types
> > > > > > (D#0001-01-01, section 2.3.3.2)
> > > > > >
> > > > > >
> > > > > >
> > > > > > > 2017-06-02 23:53 GMT+05:00 <[hidden email]
> > >:
> > > > > > >
> > > > > > > > On Friday 02 June 2017 17:20:07 beremiz-devel@lists.
> > > > sourceforge.net wrote:
> > > > > > > > > Hi Mario,
> > > > > > > > >
> > > > > > > > > On 17-06-02 16:30, [hidden email]
> > wrote:
> > > > > > > > > > On Friday 02 June 2017 08:03:53 beremiz-devel@lists.
> > > > sourceforge.net
> > > > > > > > wrote:
> > > > > > > > > > > Hi, Andrey!
> > > > > > > > > > >
> > > > > > > > > > > I think disabling locations for time related types is
> > good
> > > > temporary
> > > > > > > > > > > solution.
> > > > > > > > > > >
> > > > > > > > > > > I also think that using uint64_t for timespec is HARD
> > > > decision:
> > > > > > > > > > >    - on one hand in may solve some problems in long term;
> > > > > > > > > >   I would be OK with this being a permanent solution.
> > > > > > > > > >
> > > > > > > > > >   Since the standard:
> > > > > > > > > >     - does not specify a size for the DT data type
> > > > > > > > > >
> > > > > > > > > >         (may be implementation specific)
> > > > > > > > > >
> > > > > > > > > >     - implicitly mandates that located variables should
> > match
> > > > > > > > > >
> > > > > > > > > >         the size of the location
> > > > > > > > > if we are going to fix the problem (and I hope we are), then
> > the
> > > > > > > > > question is do we *really* want to keep size of DT the same?
> > If
> > > > we
> > > > > > > > > don't care about size of DT, then the easiest way would be
> > just
> > > > to
> > > > > > > > > increase size of 'tv_sec' field to 'uint64_t'. This will keep
> > > > most
> > > > > > > > > parts of the existing matiec code the same. Some changes to
> > > > > > > > > iec_std_lib are needed, but they are easy and obvious.
> > > > > > > > >
> > > > > > > > > struct timespec {
> > > > > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > > > > >          long     tv_nsec;       /* nanoseconds */
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > 64-bit integer value for seconds is already used in:
> > > > > > > > > - OpenBSD/NetBSD;
> > > > > > > > > - x32 ABI for GNU/Linux (32-bit API on 64-bit systems);
> > > > > > > > > - all 64-bit GNU/Linux systems.
> > > > > > > > >
> > > > > > > > > There is ongoing work to add 64-bit seconds support to 32-bit
> > > > > > > > > GNU/Linux systems for all architectures. This will be added
> > most
> > > > > > > > > likely through new syscall.
> > > > > > > > >
> > > > > > > >
> > > > > > > >   I like this method. As you say, with any luck matiec itself
> > > > would not
> > > > > > > > need to
> > > > > > > > change at all. I would actually suggest, if we are going to
> > change
> > > > this, to
> > > > > > > > change the tv_nsec too, so we can have a fixed sized of DT.
> > > > > > Some small changes will be necessary, because iec_std_lib.h
> > contains a
> > > > > > lot of typecastings to 'long int'. This has to be fixed.
> > > > > >
> > > > > >
> > > > > > > > struct timespec {
> > > > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > > > > > };
> > > > > > > >
> > > > > > > >
> > > > >
> > > >
> > > > > ------------------------------------------------------------
> > > > ------------------
> > > > > 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



------------------------------------------------------------------------------
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] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
Tomaz, have you any plans on solving problem y2038 soon for your products?


On 17-06-13 14:35, [hidden email] wrote:

> Hi, Andrey!
>
> Have you looked at my last suggested solution about adding
> >   int32_t tv_sec_ext;    /* high word for seconds */
> > to the IEC_TIMESPEC structure?
> > Any comments? Answers on questions?
>
>
> Yes, I've looked at it.
>
> There may be an issue if older runtime has some DT var and newer code calls
> some dt-related function on such variable. We could get out of bounds
> access in such case...
true

> And yes, stdlib changes are not so trivial in case of tv_sec_ext...
yes, but no black magic. It's doable.


> Could you please point to the code in stage3/stage4 that relies on
> > internal DT details?
>
>
> I've searched the code for _dt_, _timespec_, _time_, etc, and for tv_sec,
> tv_nsec.
>
> It looks like there are no direct timespec internals access in the
> translator code and we can just change std lib.
>
> So, I think no changes in translator needed, may be Mario can point to some
> "weak" places...
I couldn't find either.


>
> 2017-06-13 13:02 GMT+05:00 <[hidden email]>:
>
> > On 17-06-13 12:20, [hidden email] wrote:
> > > Hi, Andrey!
> > >
> > > As our product line is not on market yet, we can change sizes with no
> > > complain :) But others do not have such option :(
> > Same here. I don't have any problem with changing size of DT.
> > Therefore I'd like to hear their opinion and hopefully suggested solution.
> >
> > > My opinion is "the propper solution must not affect existing
> > matiec-related
> > > products, no exceptions."
> > >
> > > Yes, I'm coservative :)
> >
> > I agree with you about conservative approach.
> > Have you looked at my last suggested solution about adding
> >   int32_t tv_sec_ext;    /* high word for seconds */
> > to the IEC_TIMESPEC structure?
> > Any comments? Answers on questions?
> >
> >
> > > > All newcomers will use default values, that would generate
> > > > problematic code and then later people will probably complain about
> > > > bad code generated by matiec.
> > >
> > >
> > > We should document this issue properly, IMO this will address the problem
> > > with newcomers.
> >
> > Seriously? I see people don't even read README file for matiec to get
> > build instructions.
> >
> > > IMHO this trick will work only if we change default values to int64_t
> > > > *now*. And people who cares about backward compatibility
> > > > can set IEC_SEC_T to int32_t by defines at compile time.
> > >
> > >
> > > Default values are the minor issue the major ones are changes in
> > > iec_std_lib and
> > If we just change the size of tv_sec, then changes in iec_std_lib are
> > trivial, mostly only fixing typecasing. But anyway changes in iec_std_lib
> > doesn't cause backward compatibility issue. This is not a problem here.
> >
> >
> > > stage3-4 changes (do we need them?).
> > >
> > > Translator code must be "decoupled" from iec_std_lib to make compiletime
> > > type handling...
> > Could you please point to the code in stage3/stage4 that relies on
> > internal DT details?
> >
> > >
> > > 2017-06-13 11:58 GMT+05:00 <[hidden email]>:
> > >
> > > > On 17-06-13 11:06, [hidden email] wrote:
> > > > > Hi, Andrey!
> > > > >
> > > > > How about:
> > > > >
> > > > >
> > > > > > #ifndef IEC_SEC_T
> > > > > > #define IEC_SEC_T long int
> > > > > > #endif
> > > > > >
> > > > > > #ifndef IEC_NSEC_T
> > > > > > #define IEC_NSEC_T long int
> > > > > > #endif
> > > > >
> > > > >
> > > > > >
> > > > > typedef struct {
> > > > > >     IEC_SEC_T   tv_sec;            /* Seconds.  */
> > > > > >     IEC_NSEC_T tv_nsec;           /* Nanoseconds.  */
> > > > > > } /* __attribute__((packed)) */ IEC_TIMESPEC;  /* packed is gcc
> > > > specific!
> > > > > > */
> > > > > >
> > > > >
> > > > > In such case we have current implementation by default, and if we
> > want to
> > > > > solve 2048 problem on new devices,
> > > > > then we have to add -DIEC_SEC_T=int64_t -DIEC_NSEC_T=int32_t options
> > when
> > > > > bilding C-code.
> > > >
> > > > It is obvious solution, but the problem is here. Some questions
> > > > are still open.
> > > > When we change the default size of IEC_SEC_T and IEC_NSEC_T to int64_t?
> > > > All newcomers will use default values, that would generate
> > > > problematic code and then later people will probably complain about
> > > > bad code generated by matiec.
> > > >
> > > > IMHO this trick will work only if we change default values to int64_t
> > > > *now*. And people who cares about backward compatibility
> > > > can set IEC_SEC_T to int32_t by defines at compile time.
> > > >
> > > >
> > > > Paul, could you please say your opinion on my last suggested approach?
> > > >
> > > > > 2017-06-09 15:22 GMT+05:00 <[hidden email]>:
> > > > >
> > > > > > On 17-06-07 15:49, [hidden email] wrote:
> > > > > > > Hi!
> > > > > > >
> > > > > > > We don't really use DT much, it's usually more about counters,
> > etc.,
> > > > but
> > > > > > > this is going to change on the new controller (schedules are
> > used a
> > > > > > > lot).
> > > > > >
> > > > > > Hi Tomaz,
> > > > > >
> > > > > > thank you for the answer. Not only DT is affected, but DATE, TIME
> > and
> > > > > > TOD types. Because all these types are the same struct IEC_TIMESPEC
> > > > > > internally.
> > > > > >
> > > > > > You say you don't use DT, but you probably use timers (TON, TOF,
> > TP).
> > > > > > They use TIME and therefore rely on IEC_TIMESPEC.
> > > > > >
> > > > > >
> > > > > >
> > > > > > > The old one (MC8, microcontroller) still uses ancient gcc
> > > > > > (arm-none-eabi-gcc
> > > > > > > 4.7.2 from Yagarto), but I think it should still work.
> > > > > >
> > > > > > > I don't see too much of a problem if users need to open, fix and
> > > > rebuild
> > > > > > > some old PLC projects with DT. If it's more than that, there
> > will be
> > > > > > > complaints...
> > > > > >
> > > > > > As always the answer is 'It depends'. If during build process of
> > user
> > > > > > PLC application the program is built complete from scratch, then
> > it's
> > > > ok.
> > > > > > But if matiec generated source code is linked against precompiled
> > > > > > library, that uses IEC_TIMESPEC, then it could be a problem. For
> > > > > > example, PLC_GetTime.
> > > > > >
> > > > > > Tomaz, do you use precompiled library to build PLC program?
> > > > > > Do you struct IEC_TIMESPEC in other places than PLC_GetTime?
> > > > > > Do you have any plans on solving 2038y issue?
> > > > > >
> > > > > >
> > > > > >
> > > > > > Guys,
> > > > > >
> > > > > > what do you think if the IEC_TIMESPEC structure will look like
> > this:
> > > > > >
> > > > > > struct timespec {
> > > > > >  int32_t tv_sec;        /* seconds */
> > > > > >  int32_t tv_nsec;       /* nanoseconds */
> > > > > >  int32_t tv_sec_ext;    /* high word for seconds */
> > > > > > };
> > > > > >
> > > > > > In this case we have backward compatibility for old code, that
> > access
> > > > > > structure using pointer. Do we have cases where IEC_TIMESPEC
> > structure
> > > > > > is used as function argument by value?
> > > > > >
> > > > > >
> > > > > > > *Tomaz Orac*
> > > > > > > R&D SW manager, SMARTEH d.o.o.
> > > > > > >
> > > > > > > On 06. 06. 2017 16:31, Andrey Skvortsov wrote:
> > > > > > > > Hi Mario,
> > > > > > > >
> > > > > > > > On 17-06-04 23:48, [hidden email] wrote:
> > > > > > > > > >    Yes. I have no problem with changing the size of DT.
> > Then
> > > > > > again, I am not
> > > > > > > > > > using this in an industrial setting. Maybe other people
> > would
> > > > have
> > > > > > a
> > > > > > > > > > problem?
> > > > > > > > Sure. Let's have a discussion first and only than make some
> > such
> > > > > > changes.
> > > > > > > > I CC'd Eduard, Denis and Tomaz. Hopefully they have some
> > feedback.
> > > > > > > > Guys, what do you think about this problem and currently
> > suggested
> > > > > > solution?
> > > > > > > >
> > > > > > > > Actually everyone is welcome.
> > > > > > > >
> > > > > > > >
> > > > > > > > > struct timespec {
> > > > > > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > > > > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > > > > > > > };
> > > > > > > > >
> > > > > > > > > What about dates earlier that 1970 in case of uint we will
> > lost
> > > > them!
> > > > > > > > > And how do we going to deal with substruction of time related
> > > > types?
> > > > > > > > I agree with Paul, that tv_sec and tv_nsec should be signed
> > types.
> > > > > > > >
> > > > > > > > type_initial_value.cc contains following comment:
> > > > > > > >
> > > > > > > >    /* FIXME: Our current implementation only allows dates from
> > 1970
> > > > > > onwards,
> > > > > > > >     * but the standard defines the date 0001-01-01 as the
> > default
> > > > value
> > > > > > > >     * for the DATE data type. Untill we fix our
> > implementation, we
> > > > use
> > > > > > 1970-01-01
> > > > > > > >     * as our default value!!
> > > > > > > >     */
> > > > > > > >
> > > > > > > > with signed 64bit integer for tv_sec it's possible to represent
> > > > > > > > required by the standard initial value for DT and DATE types
> > > > > > > > (D#0001-01-01, section 2.3.3.2)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > 2017-06-02 23:53 GMT+05:00 <beremiz-devel@lists.
> > sourceforge.net
> > > > >:
> > > > > > > > >
> > > > > > > > > > On Friday 02 June 2017 17:20:07 beremiz-devel@lists.
> > > > > > sourceforge.net wrote:
> > > > > > > > > > > Hi Mario,
> > > > > > > > > > >
> > > > > > > > > > > On 17-06-02 16:30, [hidden email]
> > > > wrote:
> > > > > > > > > > > > On Friday 02 June 2017 08:03:53 beremiz-devel@lists.
> > > > > > sourceforge.net
> > > > > > > > > > wrote:
> > > > > > > > > > > > > Hi, Andrey!
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think disabling locations for time related types is
> > > > good
> > > > > > temporary
> > > > > > > > > > > > > solution.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I also think that using uint64_t for timespec is HARD
> > > > > > decision:
> > > > > > > > > > > > >    - on one hand in may solve some problems in long
> > term;
> > > > > > > > > > > >   I would be OK with this being a permanent solution.
> > > > > > > > > > > >
> > > > > > > > > > > >   Since the standard:
> > > > > > > > > > > >     - does not specify a size for the DT data type
> > > > > > > > > > > >
> > > > > > > > > > > >         (may be implementation specific)
> > > > > > > > > > > >
> > > > > > > > > > > >     - implicitly mandates that located variables should
> > > > match
> > > > > > > > > > > >
> > > > > > > > > > > >         the size of the location
> > > > > > > > > > > if we are going to fix the problem (and I hope we are),
> > then
> > > > the
> > > > > > > > > > > question is do we *really* want to keep size of DT the
> > same?
> > > > If
> > > > > > we
> > > > > > > > > > > don't care about size of DT, then the easiest way would
> > be
> > > > just
> > > > > > to
> > > > > > > > > > > increase size of 'tv_sec' field to 'uint64_t'. This will
> > keep
> > > > > > most
> > > > > > > > > > > parts of the existing matiec code the same. Some changes
> > to
> > > > > > > > > > > iec_std_lib are needed, but they are easy and obvious.
> > > > > > > > > > >
> > > > > > > > > > > struct timespec {
> > > > > > > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > > > > > > >          long     tv_nsec;       /* nanoseconds */
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > 64-bit integer value for seconds is already used in:
> > > > > > > > > > > - OpenBSD/NetBSD;
> > > > > > > > > > > - x32 ABI for GNU/Linux (32-bit API on 64-bit systems);
> > > > > > > > > > > - all 64-bit GNU/Linux systems.
> > > > > > > > > > >
> > > > > > > > > > > There is ongoing work to add 64-bit seconds support to
> > 32-bit
> > > > > > > > > > > GNU/Linux systems for all architectures. This will be
> > added
> > > > most
> > > > > > > > > > > likely through new syscall.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >   I like this method. As you say, with any luck matiec
> > itself
> > > > > > would not
> > > > > > > > > > need to
> > > > > > > > > > change at all. I would actually suggest, if we are going to
> > > > change
> > > > > > this, to
> > > > > > > > > > change the tv_nsec too, so we can have a fixed sized of DT.
> > > > > > > > Some small changes will be necessary, because iec_std_lib.h
> > > > contains a
> > > > > > > > lot of typecastings to 'long int'. This has to be fixed.
> > > > > > > >
> > > > > > > >
> > > > > > > > > > struct timespec {
> > > > > > > > > >          uint64_t tv_sec;        /* seconds */
> > > > > > > > > >          uint32_t tv_nsec;       /* nanoseconds */
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > >
> > > > > > >
> > > > > >
> > > > > > > ------------------------------------------------------------
> > > > > > ------------------
> > > > > > > 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
> >
> >

> ------------------------------------------------------------------------------
> 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] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list

Hi!

Frankly, we have no plan how to solve y2038 - I guess we are more short-sighted :) But we're definitely concerned about backward compatibility which puts us in the conservative camp :)

About your previous remarks - yes, we use TON, TOFF, etc. already on our old controller. Otherwise I grepped through it's source code and there's no use of IEC_TIMESPEC anywhere (other than in PLC_GetTime). Also the precompiled part is easily upgradeable through our IDE update and than transferred to controller without user intervention. So if I understand correctly in worst case we would have to recompile this part (not difficult) and users would have to rebuild their PLC app? If so that's not a big deal.


Tomaz Orac
R&D SW manager, SMARTEH d.o.o.

On 13. 06. 2017 12:03, Andrey Skvortsov wrote:
Tomaz, have you any plans on solving problem y2038 soon for your products?


On 17-06-13 14:35, [hidden email] wrote:
Hi, Andrey!

Have you looked at my last suggested solution about adding
  int32_t tv_sec_ext;    /* high word for seconds */
to the IEC_TIMESPEC structure?
Any comments? Answers on questions?

Yes, I've looked at it.

There may be an issue if older runtime has some DT var and newer code calls
some dt-related function on such variable. We could get out of bounds
access in such case...
true

And yes, stdlib changes are not so trivial in case of tv_sec_ext...
yes, but no black magic. It's doable.


Could you please point to the code in stage3/stage4 that relies on
internal DT details?

I've searched the code for _dt_, _timespec_, _time_, etc, and for tv_sec,
tv_nsec.

It looks like there are no direct timespec internals access in the
translator code and we can just change std lib.

So, I think no changes in translator needed, may be Mario can point to some
"weak" places...
I couldn't find either.


2017-06-13 13:02 GMT+05:00 [hidden email]:

On 17-06-13 12:20, [hidden email] wrote:
Hi, Andrey!

As our product line is not on market yet, we can change sizes with no
complain :) But others do not have such option :(
Same here. I don't have any problem with changing size of DT.
Therefore I'd like to hear their opinion and hopefully suggested solution.

My opinion is "the propper solution must not affect existing
matiec-related
products, no exceptions."

Yes, I'm coservative :)
I agree with you about conservative approach.
Have you looked at my last suggested solution about adding
  int32_t tv_sec_ext;    /* high word for seconds */
to the IEC_TIMESPEC structure?
Any comments? Answers on questions?


All newcomers will use default values, that would generate
problematic code and then later people will probably complain about
bad code generated by matiec.

We should document this issue properly, IMO this will address the problem
with newcomers.
Seriously? I see people don't even read README file for matiec to get
build instructions.

IMHO this trick will work only if we change default values to int64_t
*now*. And people who cares about backward compatibility
can set IEC_SEC_T to int32_t by defines at compile time.

Default values are the minor issue the major ones are changes in
iec_std_lib and
If we just change the size of tv_sec, then changes in iec_std_lib are
trivial, mostly only fixing typecasing. But anyway changes in iec_std_lib
doesn't cause backward compatibility issue. This is not a problem here.


stage3-4 changes (do we need them?).

Translator code must be "decoupled" from iec_std_lib to make compiletime
type handling...
Could you please point to the code in stage3/stage4 that relies on
internal DT details?

2017-06-13 11:58 GMT+05:00 [hidden email]:

On 17-06-13 11:06, [hidden email] wrote:
Hi, Andrey!

How about:


#ifndef IEC_SEC_T
#define IEC_SEC_T long int
#endif

#ifndef IEC_NSEC_T
#define IEC_NSEC_T long int
#endif


                
typedef struct {
    IEC_SEC_T   tv_sec;            /* Seconds.  */
    IEC_NSEC_T tv_nsec;           /* Nanoseconds.  */
} /* __attribute__((packed)) */ IEC_TIMESPEC;  /* packed is gcc
specific!
*/

In such case we have current implementation by default, and if we
want to
solve 2048 problem on new devices,
then we have to add -DIEC_SEC_T=int64_t -DIEC_NSEC_T=int32_t options
when
bilding C-code.
It is obvious solution, but the problem is here. Some questions
are still open.
When we change the default size of IEC_SEC_T and IEC_NSEC_T to int64_t?
All newcomers will use default values, that would generate
problematic code and then later people will probably complain about
bad code generated by matiec.

IMHO this trick will work only if we change default values to int64_t
*now*. And people who cares about backward compatibility
can set IEC_SEC_T to int32_t by defines at compile time.


Paul, could you please say your opinion on my last suggested approach?

2017-06-09 15:22 GMT+05:00 [hidden email]:

On 17-06-07 15:49, [hidden email] wrote:
Hi!

We don't really use DT much, it's usually more about counters,
etc.,
but
this is going to change on the new controller (schedules are
used a
lot).
Hi Tomaz,

thank you for the answer. Not only DT is affected, but DATE, TIME
and
TOD types. Because all these types are the same struct IEC_TIMESPEC
internally.

You say you don't use DT, but you probably use timers (TON, TOF,
TP).
They use TIME and therefore rely on IEC_TIMESPEC.



The old one (MC8, microcontroller) still uses ancient gcc
(arm-none-eabi-gcc
4.7.2 from Yagarto), but I think it should still work.

                  
I don't see too much of a problem if users need to open, fix and
rebuild
some old PLC projects with DT. If it's more than that, there
will be
complaints...
As always the answer is 'It depends'. If during build process of
user
PLC application the program is built complete from scratch, then
it's
ok.
But if matiec generated source code is linked against precompiled
library, that uses IEC_TIMESPEC, then it could be a problem. For
example, PLC_GetTime.

Tomaz, do you use precompiled library to build PLC program?
Do you struct IEC_TIMESPEC in other places than PLC_GetTime?
Do you have any plans on solving 2038y issue?



Guys,

what do you think if the IEC_TIMESPEC structure will look like
this:
struct timespec {
 int32_t tv_sec;        /* seconds */
 int32_t tv_nsec;       /* nanoseconds */
 int32_t tv_sec_ext;    /* high word for seconds */
};

In this case we have backward compatibility for old code, that
access
structure using pointer. Do we have cases where IEC_TIMESPEC
structure
is used as function argument by value?


*Tomaz Orac*
R&D SW manager, SMARTEH d.o.o.

On 06. 06. 2017 16:31, Andrey Skvortsov wrote:
Hi Mario,

On 17-06-04 23:48, [hidden email] wrote:
   Yes. I have no problem with changing the size of DT.
Then
again, I am not
using this in an industrial setting. Maybe other people
would
have
a
problem?
Sure. Let's have a discussion first and only than make some
such
changes.
I CC'd Eduard, Denis and Tomaz. Hopefully they have some
feedback.
Guys, what do you think about this problem and currently
suggested
solution?
Actually everyone is welcome.


struct timespec {
         uint64_t tv_sec;        /* seconds */
         uint32_t tv_nsec;       /* nanoseconds */
};
What about dates earlier that 1970 in case of uint we will
lost
them!
And how do we going to deal with substruction of time related
types?
I agree with Paul, that tv_sec and tv_nsec should be signed
types.
type_initial_value.cc contains following comment:

   /* FIXME: Our current implementation only allows dates from
1970
onwards,
    * but the standard defines the date 0001-01-01 as the
default
value
    * for the DATE data type. Untill we fix our
implementation, we
use
1970-01-01
    * as our default value!!
    */

with signed 64bit integer for tv_sec it's possible to represent
required by the standard initial value for DT and DATE types
(D#0001-01-01, section 2.3.3.2)



2017-06-02 23:53 GMT+05:00 <beremiz-devel@lists.
sourceforge.net
:

                        
On Friday 02 June 2017 17:20:07 beremiz-devel@lists.
sourceforge.net wrote:
Hi Mario,

On 17-06-02 16:30, [hidden email]
wrote:
On Friday 02 June 2017 08:03:53 beremiz-devel@lists.
sourceforge.net
wrote:
Hi, Andrey!

I think disabling locations for time related types is
good
temporary
solution.

I also think that using uint64_t for timespec is HARD
decision:
   - on one hand in may solve some problems in long
term;
  I would be OK with this being a permanent solution.

  Since the standard:
    - does not specify a size for the DT data type

        (may be implementation specific)

    - implicitly mandates that located variables should
match
        the size of the location
if we are going to fix the problem (and I hope we are),
then
the
question is do we *really* want to keep size of DT the
same?
If
we
don't care about size of DT, then the easiest way would
be
just
to
increase size of 'tv_sec' field to 'uint64_t'. This will
keep
most
parts of the existing matiec code the same. Some changes
to
iec_std_lib are needed, but they are easy and obvious.

struct timespec {
         uint64_t tv_sec;        /* seconds */
         long     tv_nsec;       /* nanoseconds */
};

64-bit integer value for seconds is already used in:
- OpenBSD/NetBSD;
- x32 ABI for GNU/Linux (32-bit API on 64-bit systems);
- all 64-bit GNU/Linux systems.

There is ongoing work to add 64-bit seconds support to
32-bit
GNU/Linux systems for all architectures. This will be
added
most
likely through new syscall.

  I like this method. As you say, with any luck matiec
itself
would not
need to
change at all. I would actually suggest, if we are going to
change
this, to
change the tv_nsec too, so we can have a fixed sized of DT.
Some small changes will be necessary, because iec_std_lib.h
contains a
lot of typecastings to 'long int'. This has to be fixed.


struct timespec {
         uint64_t tv_sec;        /* seconds */
         uint32_t tv_nsec;       /* nanoseconds */
};



                  

                  
------------------------------------------------------------
------------------
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



      
------------------------------------------------------------------------------
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
12