Re: [Beremiz-devel] Beremiz-devel Digest, Vol 89, Issue 2

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

Re: [Beremiz-devel] Beremiz-devel Digest, Vol 89, Issue 2

Beremiz-Devel mailing list

I must say that this is code for the matiec!


10.04.2018 14:53, [hidden email] пишет:
Message: 2
Date: Tue, 10 Apr 2018 14:39:29 +0500
From: [hidden email]
To: [hidden email]
Subject: Re: [Beremiz-devel] Beremiz-devel Digest, Vol 89, Issue 1
Message-ID:
	[hidden email]
Content-Type: text/plain; charset="utf-8"; Format="flowed"

As a temporary workaround I propose to do the following:

1 Since task intervals (used in resource1.c) already have a common 
divisor equal to "1", after counting common_ticktime__
The search for the largest number can be reduced to the following:

unsigned long tick_mod_array[task_num]; // array of tick tasks, before 
calculate "common_ticktime__"
For example:
 >void RESOURCE1_run__(unsigned long tick) {
 >? TASK1 = !(tick % 2500);
 >? TASK2 = !(tick % 2501);
 >? TASK3 = !(tick % 2500);
 >? TASK3 = !(tick % 3000);
 >? TASK3 = !(tick % 500);

unsigned long tick_mod_array[] = {2500, 2501, 2500, 3000, 500};


unsigned long get_greatest_tick()
{
 ??? unsigned long long greatest_tick = tick_mod_array[0];
 ??? for(char(?) i = 1; i < task_num; i++)
 ??? {
 ??????? if (greatest_tick < tick_mod_array[i]) {
 ??????????? if(tick_mod_array[i] % greatest_tick) {
 ??????????????? greatest_tick *= tick_mod_array[i];
 ??????????? } else {
 ??????????????? greatest_tick = tick_mod_array[i];
 ??????????? }
 ??????? } else {
 ??????????? if (greatest_tick != tick_mod_array[i]) {
 ??????????????? if (greatest_tick % tick_mod_array[i]) {
 ??????????????????? greatest_tick *= tick_mod_array[i];
 ??????????????? } else {
 ??????????????????? //greatest_tick = greatest_tick;
 ??????????????? }
 ??????????? } else {
 ??????????????? // greatest_tick == tick_mod_array[i]
 ??????????????? // continue
 ??????????? }
 ??????? }
 ??? }

 ??? for found max for range unsigned long:
 ??? if (greatest_tick >> 32) {
 ??????? ERROR;
 ??? } else {
 ??????? greatest_tick *= (((unsigned long)(-1)) / greatest_tick);
 ??? }
 ??? return (unsigned long)greatest_tick;
}

I ran a simple test for this code. It's Ok!

But there is another problem -? out of range unsigned long!

Thanks!

-- 
С уважением,
Сафронов Александр
Инженер отдела разработки
ООО "К-СОФТ ИНЖИНИРИНГ"
Best Regards,
Safronov Aleksandr
Developer, Firmware Development Team
LLC "K-SOFT ENGINEERING"

------------------------------------------------------------------------------
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] Calculate greatest_tick_count__

Beremiz-Devel mailing list


 HI Aleksandr,

 Yes, it seems that this would fix the problem you mentioned.

 However, my opinion is that if we are going to mess around with this code, it
would be better if we could fix this properly. What I mean by this is that:

0) Recognize that it should not be the compiler's (matiec) responsibility to
include code that calls the tasks periodically. This functionality should be
provided instead by the runtime environment.


1)
  The compiler (matiec) should simply set up an array of struct with the
information required to execute the tasks periodically.

typedef task_into_t {
  int period;
  void (*func) (void);
  ...
}

task_info_t task_info[3] = {
  {3, task0},
  {10, task1}
};


2)
 It should then be up to the runtime to do what it needs to call the tasks
periodically.
 When running on a POSIX operating system, tasks may be mapped onto threads.
 When running on an embedded system with no operating system, then the cyclic
scheduler (while(1) loop) may be used instead.


 NOTE: This means that all runtime systems currently using Beremiz/matiec will
need to be updated, which is why I have been putting off this change.


 Cheers,

    Mario.




On Wednesday, April 11, 2018 14:05:31 [hidden email]
wrote:

> I must say that this is code for the matiec!
>
> 10.04.2018 14:53, [hidden email] пишет:
> > Message: 2
> > Date: Tue, 10 Apr 2018 14:39:29 +0500
> > From:[hidden email]
> > To:<[hidden email]>
> > Subject: Re: [Beremiz-devel] Beremiz-devel Digest, Vol 89, Issue 1
> >
> > Message-ID:
> > <[hidden email]>
> >
> > Content-Type: text/plain; charset="utf-8"; Format="flowed"
> >
> > As a temporary workaround I propose to do the following:
> >
> > 1 Since task intervals (used in resource1.c) already have a common
> > divisor equal to "1", after counting common_ticktime__
> > The search for the largest number can be reduced to the following:
> >
> > unsigned long tick_mod_array[task_num]; // array of tick tasks, before
> > calculate "common_ticktime__"
> >
> > For example:
> >   >void RESOURCE1_run__(unsigned long tick) {
> >   >? TASK1 = !(tick % 2500);
> >   >? TASK2 = !(tick % 2501);
> >   >? TASK3 = !(tick % 2500);
> >   >? TASK3 = !(tick % 3000);
> >   >? TASK3 = !(tick % 500);
> >
> > unsigned long tick_mod_array[] = {2500, 2501, 2500, 3000, 500};
> >
> >
> > unsigned long get_greatest_tick()
> > {
> >
> >   ??? unsigned long long greatest_tick = tick_mod_array[0];
> >   ??? for(char(?) i = 1; i < task_num; i++)
> >   ??? {
> >   ??????? if (greatest_tick < tick_mod_array[i]) {
> >   ??????????? if(tick_mod_array[i] % greatest_tick) {
> >   ??????????????? greatest_tick *= tick_mod_array[i];
> >   ??????????? } else {
> >   ??????????????? greatest_tick = tick_mod_array[i];
> >   ??????????? }
> >   ??????? } else {
> >   ??????????? if (greatest_tick != tick_mod_array[i]) {
> >   ??????????????? if (greatest_tick % tick_mod_array[i]) {
> >   ??????????????????? greatest_tick *= tick_mod_array[i];
> >   ??????????????? } else {
> >   ??????????????????? //greatest_tick = greatest_tick;
> >   ??????????????? }
> >   ??????????? } else {
> >   ??????????????? // greatest_tick == tick_mod_array[i]
> >   ??????????????? // continue
> >   ??????????? }
> >   ??????? }
> >   ??? }
> >  
> >   ??? for found max for range unsigned long:
> >   ??? if (greatest_tick >> 32) {
> >   ??????? ERROR;
> >   ??? } else {
> >   ??????? greatest_tick *= (((unsigned long)(-1)) / greatest_tick);
> >   ??? }
> >   ??? return (unsigned long)greatest_tick;
> >
> > }
> >
> > I ran a simple test for this code. It's Ok!
> >
> > But there is another problem -? out of range unsigned long!
> >
> > Thanks!


------------------------------------------------------------------------------
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] Calculate greatest_tick_count__

Beremiz-Devel mailing list
Hi, Mario!

  Such decision will also affect iec_std _lib as people will have to add mutexes everywhere!

  And what about interrupts/nonperiodic events?

  What if we just recalculate greatest tick count as less common multiple of all task petiods devided by common tick time ?

Best regards,
Paul Beltyukov

2018-04-11 18:57 GMT+05:00 <[hidden email]>:


 HI Aleksandr,

 Yes, it seems that this would fix the problem you mentioned.

 However, my opinion is that if we are going to mess around with this code, it
would be better if we could fix this properly. What I mean by this is that:

0) Recognize that it should not be the compiler's (matiec) responsibility to
include code that calls the tasks periodically. This functionality should be
provided instead by the runtime environment.


1)
  The compiler (matiec) should simply set up an array of struct with the
information required to execute the tasks periodically.

typedef task_into_t {
  int period;
  void (*func) (void);
  ...
}

task_info_t task_info[3] = {
  {3, task0},
  {10, task1}
};


2)
 It should then be up to the runtime to do what it needs to call the tasks
periodically.
 When running on a POSIX operating system, tasks may be mapped onto threads.
 When running on an embedded system with no operating system, then the cyclic
scheduler (while(1) loop) may be used instead.


 NOTE: This means that all runtime systems currently using Beremiz/matiec will
need to be updated, which is why I have been putting off this change.


 Cheers,

    Mario.




On Wednesday, April 11, 2018 14:05:31 [hidden email]
wrote:
> I must say that this is code for the matiec!
>
> 10.04.2018 14:53, [hidden email] пишет:
> > Message: 2
> > Date: Tue, 10 Apr 2018 14:39:29 +0500
> > [hidden email]
> > To:<[hidden email]>
> > Subject: Re: [Beremiz-devel] Beremiz-devel Digest, Vol 89, Issue 1
> >
> > Message-ID:
> >     <[hidden email]>
> >
> > Content-Type: text/plain; charset="utf-8"; Format="flowed"
> >
> > As a temporary workaround I propose to do the following:
> >
> > 1 Since task intervals (used in resource1.c) already have a common
> > divisor equal to "1", after counting common_ticktime__
> > The search for the largest number can be reduced to the following:
> >
> > unsigned long tick_mod_array[task_num]; // array of tick tasks, before
> > calculate "common_ticktime__"
> >
> > For example:
> >   >void RESOURCE1_run__(unsigned long tick) {
> >   >? TASK1 = !(tick % 2500);
> >   >? TASK2 = !(tick % 2501);
> >   >? TASK3 = !(tick % 2500);
> >   >? TASK3 = !(tick % 3000);
> >   >? TASK3 = !(tick % 500);
> >
> > unsigned long tick_mod_array[] = {2500, 2501, 2500, 3000, 500};
> >
> >
> > unsigned long get_greatest_tick()
> > {
> >
> >   ??? unsigned long long greatest_tick = tick_mod_array[0];
> >   ??? for(char(?) i = 1; i < task_num; i++)
> >   ??? {
> >   ??????? if (greatest_tick < tick_mod_array[i]) {
> >   ??????????? if(tick_mod_array[i] % greatest_tick) {
> >   ??????????????? greatest_tick *= tick_mod_array[i];
> >   ??????????? } else {
> >   ??????????????? greatest_tick = tick_mod_array[i];
> >   ??????????? }
> >   ??????? } else {
> >   ??????????? if (greatest_tick != tick_mod_array[i]) {
> >   ??????????????? if (greatest_tick % tick_mod_array[i]) {
> >   ??????????????????? greatest_tick *= tick_mod_array[i];
> >   ??????????????? } else {
> >   ??????????????????? //greatest_tick = greatest_tick;
> >   ??????????????? }
> >   ??????????? } else {
> >   ??????????????? // greatest_tick == tick_mod_array[i]
> >   ??????????????? // continue
> >   ??????????? }
> >   ??????? }
> >   ??? }
> >   
> >   ??? for found max for range unsigned long:
> >   ??? if (greatest_tick >> 32) {
> >   ??????? ERROR;
> >   ??? } else {
> >   ??????? greatest_tick *= (((unsigned long)(-1)) / greatest_tick);
> >   ??? }
> >   ??? return (unsigned long)greatest_tick;
> >
> > }
> >
> > I ran a simple test for this code. It's Ok!
> >
> > But there is another problem -? out of range unsigned long!
> >
> > Thanks!


------------------------------------------------------------------------------
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] Calculate greatest_tick_count__

Beremiz-Devel mailing list

 

On Thursday, April 12, 2018 13:19:09 [hidden email]
wrote:
>   Such decision will also affect iec_std _lib as people will have to add
> mutexes everywhere!

Short answer:
 Yep, but this is a choice the user/programmer has. Maybe he _wants_ the tasks
to interrupt each other. We should give him/her this choice.


Long answer:
 I still believe the compiler should not be forcing the scheduling
options/decisions. It should be the runtime that chooses which method to use.

 With my approach you are not forced to use POSIX threads on a POSIX operating
system. It is an option. You are perfectly allowed to still implement a non-
preemptabe cyclic executive on top of a POSIX operating system if that is what
you need.

 In summary with my approach you have a choice, unlike the current situation
where you are forced onto a fixed design decision.


 It should be possible to have a BEremiz project configuration option that lets
the user choose which runtime (scheduling algorithm) should be used. We can
have two runtime versions for POSIX, one using non-preemptable scheduling, and
another using preemptable threads.


>
>   And what about interrupts/nonperiodic events?

 Map them onto the task structure too, and let the runtime handle them how it
sees fit.


   Mario.


>
>   What if we just recalculate greatest tick count as less common multiple
> of all task petiods devided by common tick time ?
>
> Best regards,
> Paul Beltyukov
>
> 2018-04-11 18:57 GMT+05:00 <[hidden email]>:
> >  HI Aleksandr,
> >  
> >  Yes, it seems that this would fix the problem you mentioned.
> >  
> >  However, my opinion is that if we are going to mess around with this
> >
> > code, it
> > would be better if we could fix this properly. What I mean by this is
> > that:
> >
> > 0) Recognize that it should not be the compiler's (matiec) responsibility
> > to
> > include code that calls the tasks periodically. This functionality should
> > be
> > provided instead by the runtime environment.
> >
> >
> > 1)
> >
> >   The compiler (matiec) should simply set up an array of struct with the
> >
> > information required to execute the tasks periodically.
> >
> > typedef task_into_t {
> >
> >   int period;
> >   void (*func) (void);
> >   ...
> >
> > }
> >
> > task_info_t task_info[3] = {
> >
> >   {3, task0},
> >   {10, task1}
> >
> > };
> >
> >
> > 2)
> >
> >  It should then be up to the runtime to do what it needs to call the tasks
> >
> > periodically.
> >
> >  When running on a POSIX operating system, tasks may be mapped onto
> >
> > threads.
> >
> >  When running on an embedded system with no operating system, then the
> >
> > cyclic
> > scheduler (while(1) loop) may be used instead.
> >
> >  NOTE: This means that all runtime systems currently using Beremiz/matiec
> >
> > will
> > need to be updated, which is why I have been putting off this change.
> >
> >  Cheers,
> >  
> >     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] Calculate greatest_tick_count__

Beremiz-Devel mailing list
If we are going to break tha backward compatibility,  then I think 
it's time to consider other issues such as y2038 + 64/32-host-target-conflict
which are the one issue from technical point of view, UTF8 string literals and so on.

Regards,
Paul Beltyukov

2018-04-12 16:34 GMT+05:00 <[hidden email]>:



On Thursday, April 12, 2018 13:19:09 [hidden email]
wrote:
>   Such decision will also affect iec_std _lib as people will have to add
> mutexes everywhere!

Short answer:
 Yep, but this is a choice the user/programmer has. Maybe he _wants_ the tasks
to interrupt each other. We should give him/her this choice.


Long answer:
 I still believe the compiler should not be forcing the scheduling
options/decisions. It should be the runtime that chooses which method to use.

 With my approach you are not forced to use POSIX threads on a POSIX operating
system. It is an option. You are perfectly allowed to still implement a non-
preemptabe cyclic executive on top of a POSIX operating system if that is what
you need.

 In summary with my approach you have a choice, unlike the current situation
where you are forced onto a fixed design decision.


 It should be possible to have a BEremiz project configuration option that lets
the user choose which runtime (scheduling algorithm) should be used. We can
have two runtime versions for POSIX, one using non-preemptable scheduling, and
another using preemptable threads.


>
>   And what about interrupts/nonperiodic events?

 Map them onto the task structure too, and let the runtime handle them how it
sees fit.


   Mario.


>
>   What if we just recalculate greatest tick count as less common multiple
> of all task petiods devided by common tick time ?
>
> Best regards,
> Paul Beltyukov
>
> 2018-04-11 18:57 GMT+05:00 <[hidden email]>:
> >  HI Aleksandr,
> > 
> >  Yes, it seems that this would fix the problem you mentioned.
> > 
> >  However, my opinion is that if we are going to mess around with this
> >
> > code, it
> > would be better if we could fix this properly. What I mean by this is
> > that:
> >
> > 0) Recognize that it should not be the compiler's (matiec) responsibility
> > to
> > include code that calls the tasks periodically. This functionality should
> > be
> > provided instead by the runtime environment.
> >
> >
> > 1)
> >
> >   The compiler (matiec) should simply set up an array of struct with the
> >
> > information required to execute the tasks periodically.
> >
> > typedef task_into_t {
> >
> >   int period;
> >   void (*func) (void);
> >   ...
> >
> > }
> >
> > task_info_t task_info[3] = {
> >
> >   {3, task0},
> >   {10, task1}
> >
> > };
> >
> >
> > 2)
> >
> >  It should then be up to the runtime to do what it needs to call the tasks
> >
> > periodically.
> >
> >  When running on a POSIX operating system, tasks may be mapped onto
> >
> > threads.
> >
> >  When running on an embedded system with no operating system, then the
> >
> > cyclic
> > scheduler (while(1) loop) may be used instead.
> >
> >  NOTE: This means that all runtime systems currently using Beremiz/matiec
> >
> > will
> > need to be updated, which is why I have been putting off this change.
> >
> >  Cheers,
> > 
> >     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] Calculate greatest_tick_count__

Beremiz-Devel mailing list

On Thursday, April 12, 2018 16:52:16 [hidden email]
wrote:
> If we are going to break tha backward compatibility,  then I think
> it's time to consider other issues such as y2038 +
> 64/32-host-target-conflict
> which are the one issue from technical point of view, UTF8 string literals
> and so on.


 Yeah, the problem here is mostly who is going to do this?
 These changes take time and effort. Especially the UTF8 issue (unless you have
an idea of how to go about doing it in an elegant way?).

 I haven't spent much time looking into how we could fix this, but currently it
seems to me that fixing the UTF8 issue means throwing away the matiec's front-
end and re-doing it all again from scratch. In other words, re-writing a 1/3
of matiec from scratch. Any volunteers?

 I have actually started implementing a brand new front-end (for another
reason) that would also solve this problem, but I don't know if it will ever
get finished. I don't need it for myself, and lately I have prefered to give
priority to other (family related) activities over the weekends.




   Cheers,

          Mario.


P.S.: (if you wish, send me a private email and we can continue this
discussion off list - msousa @ fe.up.pt)

>
> Regards,
> Paul Beltyukov
>
> 2018-04-12 16:34 GMT+05:00 <[hidden email]>:
> > On Thursday, April 12, 2018 13:19:09 [hidden email]
> >
> > wrote:
> > >   Such decision will also affect iec_std _lib as people will have to add
> > >
> > > mutexes everywhere!
> >
> > Short answer:
> >  Yep, but this is a choice the user/programmer has. Maybe he _wants_ the
> >
> > tasks
> > to interrupt each other. We should give him/her this choice.
> >
> > Long answer:
> >  I still believe the compiler should not be forcing the scheduling
> >
> > options/decisions. It should be the runtime that chooses which method to
> > use.
> >
> >  With my approach you are not forced to use POSIX threads on a POSIX
> >
> > operating
> > system. It is an option. You are perfectly allowed to still implement a
> > non-
> > preemptabe cyclic executive on top of a POSIX operating system if that is
> > what
> > you need.
> >
> >  In summary with my approach you have a choice, unlike the current
> >
> > situation
> > where you are forced onto a fixed design decision.
> >
> >  It should be possible to have a BEremiz project configuration option that
> >
> > lets
> > the user choose which runtime (scheduling algorithm) should be used. We
> > can
> > have two runtime versions for POSIX, one using non-preemptable scheduling,
> > and
> > another using preemptable threads.
> >
> > >   And what about interrupts/nonperiodic events?
> >  
> >  Map them onto the task structure too, and let the runtime handle them how
> >
> > it
> > sees fit.
> >
> >    Mario.
> >    
> > >   What if we just recalculate greatest tick count as less common
> > >   multiple
> > >
> > > of all task petiods devided by common tick time ?
> > >
> > > Best regards,
> > > Paul Beltyukov
> > >
> > > 2018-04-11 18:57 GMT+05:00 <[hidden email]>:
> > > >  HI Aleksandr,
> > > >  
> > > >  Yes, it seems that this would fix the problem you mentioned.
> > > >  
> > > >  However, my opinion is that if we are going to mess around with this
> > > >
> > > > code, it
> > > > would be better if we could fix this properly. What I mean by this is
> > > > that:
> > > >
> > > > 0) Recognize that it should not be the compiler's (matiec)
> >
> > responsibility
> >
> > > > to
> > > > include code that calls the tasks periodically. This functionality
> >
> > should
> >
> > > > be
> > > > provided instead by the runtime environment.
> > > >
> > > >
> > > > 1)
> > > >
> > > >   The compiler (matiec) should simply set up an array of struct with
> >
> > the
> >
> > > > information required to execute the tasks periodically.
> > > >
> > > > typedef task_into_t {
> > > >
> > > >   int period;
> > > >   void (*func) (void);
> > > >   ...
> > > >
> > > > }
> > > >
> > > > task_info_t task_info[3] = {
> > > >
> > > >   {3, task0},
> > > >   {10, task1}
> > > >
> > > > };
> > > >
> > > >
> > > > 2)
> > > >
> > > >  It should then be up to the runtime to do what it needs to call the
> >
> > tasks
> >
> > > > periodically.
> > > >
> > > >  When running on a POSIX operating system, tasks may be mapped onto
> > > >
> > > > threads.
> > > >
> > > >  When running on an embedded system with no operating system, then the
> > > >
> > > > cyclic
> > > > scheduler (while(1) loop) may be used instead.
> > > >
> > > >  NOTE: This means that all runtime systems currently using
> >
> > Beremiz/matiec
> >
> > > > will
> > > > need to be updated, which is why I have been putting off this change.
> > > >
> > > >  Cheers,
> > > >  
> > > >     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] Calculate greatest_tick_count__

Beremiz-Devel mailing list
Hi, Mario!

 The UTF8 issue is 

And I think that it is not so serious to rewrite the frontend...
My suggestion on it was to correct the definition of 

common_character_representation     

in iec_flex.ll line 834 to 

utf_8_start_char    [\xC0-\xDF]|[\xE0-\xEF]|[\xF0-\xF7]
utf_8_end_char     [\x80-\xBF]
utf_8_char             {utf_8_start_char}|{utf_8_end_char}
common_character_representation     [\x20\x21\x23\x25\x26\x28-\x7E]|{utf_8_char}|{esc_char}

and make C-compiler of runtime responsible for actual string checking/handling/normalization.

But probably I couldn't see some deeper issues, please correct me if my suggestion was wrong...

The y2038-problem as I remember may be fixed at iec_std_lib level with very few Beremiz changes, so it's not very dramatic too...

> Any volunteers?
Well, currently I have to work on two projecs and I will be less busy by the summer, so I may be I could spend some time on these issues.

Best regards,
Paul Beltyukov

2018-04-12 18:41 GMT+05:00 <[hidden email]>:

On Thursday, April 12, 2018 16:52:16 [hidden email]
wrote:
> If we are going to break tha backward compatibility,  then I think
> it's time to consider other issues such as y2038 +
> 64/32-host-target-conflict
> which are the one issue from technical point of view, UTF8 string literals
> and so on.


 Yeah, the problem here is mostly who is going to do this?
 These changes take time and effort. Especially the UTF8 issue (unless you have
an idea of how to go about doing it in an elegant way?).

 I haven't spent much time looking into how we could fix this, but currently it
seems to me that fixing the UTF8 issue means throwing away the matiec's front-
end and re-doing it all again from scratch. In other words, re-writing a 1/3
of matiec from scratch. Any volunteers?

 I have actually started implementing a brand new front-end (for another
reason) that would also solve this problem, but I don't know if it will ever
get finished. I don't need it for myself, and lately I have prefered to give
priority to other (family related) activities over the weekends.




   Cheers,

          Mario.


P.S.: (if you wish, send me a private email and we can continue this
discussion off list - msousa @ fe.up.pt)

>
> Regards,
> Paul Beltyukov
>
> 2018-04-12 16:34 GMT+05:00 <[hidden email]>:
> > On Thursday, April 12, 2018 13:19:09 [hidden email]
> >
> > wrote:
> > >   Such decision will also affect iec_std _lib as people will have to add
> > >
> > > mutexes everywhere!
> >
> > Short answer:
> >  Yep, but this is a choice the user/programmer has. Maybe he _wants_ the
> >
> > tasks
> > to interrupt each other. We should give him/her this choice.
> >
> > Long answer:
> >  I still believe the compiler should not be forcing the scheduling
> >
> > options/decisions. It should be the runtime that chooses which method to
> > use.
> >
> >  With my approach you are not forced to use POSIX threads on a POSIX
> >
> > operating
> > system. It is an option. You are perfectly allowed to still implement a
> > non-
> > preemptabe cyclic executive on top of a POSIX operating system if that is
> > what
> > you need.
> >
> >  In summary with my approach you have a choice, unlike the current
> >
> > situation
> > where you are forced onto a fixed design decision.
> >
> >  It should be possible to have a BEremiz project configuration option that
> >
> > lets
> > the user choose which runtime (scheduling algorithm) should be used. We
> > can
> > have two runtime versions for POSIX, one using non-preemptable scheduling,
> > and
> > another using preemptable threads.
> >
> > >   And what about interrupts/nonperiodic events?
> > 
> >  Map them onto the task structure too, and let the runtime handle them how
> >
> > it
> > sees fit.
> >
> >    Mario.
> >   
> > >   What if we just recalculate greatest tick count as less common
> > >   multiple
> > >
> > > of all task petiods devided by common tick time ?
> > >
> > > Best regards,
> > > Paul Beltyukov
> > >
> > > 2018-04-11 18:57 GMT+05:00 <[hidden email]>:
> > > >  HI Aleksandr,
> > > > 
> > > >  Yes, it seems that this would fix the problem you mentioned.
> > > > 
> > > >  However, my opinion is that if we are going to mess around with this
> > > >
> > > > code, it
> > > > would be better if we could fix this properly. What I mean by this is
> > > > that:
> > > >
> > > > 0) Recognize that it should not be the compiler's (matiec)
> >
> > responsibility
> >
> > > > to
> > > > include code that calls the tasks periodically. This functionality
> >
> > should
> >
> > > > be
> > > > provided instead by the runtime environment.
> > > >
> > > >
> > > > 1)
> > > >
> > > >   The compiler (matiec) should simply set up an array of struct with
> >
> > the
> >
> > > > information required to execute the tasks periodically.
> > > >
> > > > typedef task_into_t {
> > > >
> > > >   int period;
> > > >   void (*func) (void);
> > > >   ...
> > > >
> > > > }
> > > >
> > > > task_info_t task_info[3] = {
> > > >
> > > >   {3, task0},
> > > >   {10, task1}
> > > >
> > > > };
> > > >
> > > >
> > > > 2)
> > > >
> > > >  It should then be up to the runtime to do what it needs to call the
> >
> > tasks
> >
> > > > periodically.
> > > >
> > > >  When running on a POSIX operating system, tasks may be mapped onto
> > > >
> > > > threads.
> > > >
> > > >  When running on an embedded system with no operating system, then the
> > > >
> > > > cyclic
> > > > scheduler (while(1) loop) may be used instead.
> > > >
> > > >  NOTE: This means that all runtime systems currently using
> >
> > Beremiz/matiec
> >
> > > > will
> > > > need to be updated, which is why I have been putting off this change.
> > > >
> > > >  Cheers,
> > > > 
> > > >     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] Calculate greatest_tick_count__

Beremiz-Devel mailing list
On Friday, April 13, 2018 09:05:14 [hidden email] wrote:
> Hi, Mario!
>
>  The UTF8 issue is
> https://bitbucket.org/mjsousa/matiec/issues/60/matiec-fails-to-parse-russian
> -strings
>
> And I think that it is not so serious to rewrite the frontend...
> My suggestion on it was to correct the definition of


 Hmmm...  You are correct. I was being stupid and understood the issue as you
requesting that all source code be Unicode compatible, including names used
for identifiers (functions/FB/variables/...) comments, whitespaces, etc...

 This would really imply big changes.

 If it is only for strings then it might be possible. It seems you have given
this more thought than I. If you have a solution, please feel free to send me
a patch.


   Cheers,

       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