[Beremiz-devel] The output file of beremiz is real machine code????

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

[Beremiz-devel] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
Hi,
The beremize's executive process as fowllow:

IEC61131-3 ST/IL——>C code——>output file

I have two qustions:
(1)the output file is binary code???
(2)the output file is real machine code???



--
Sent from: http://beremiz-devel.2374573.n4.nabble.com/

------------------------------------------------------------------------------
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] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
On 18-01-23 02:13, [hidden email] wrote:
> Hi,
> The beremize's executive process as fowllow:
>
> IEC61131-3 ST/IL——>C code——>output file
>
> I have two qustions:
> (1)the output file is binary code???
> (2)the output file is real machine code???
>

End result is real machine code of your target.

--
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] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
Hi,
Thanks your reply.
I have learned about some other plc tools,such as multiprog and codesys.
And I have test the benchmark of mulitprog and codesys

1000 line BOOL IL test ,the result as follows:

multiprog:3-4us
codesys:2-3us
beremiz:200us

The gap is clearly , so I doubt the output file is real machine code ,cpu's
instructon list code.

Not the the middle code which runtime to analysis and to execute

so ,what's the real reason of the so big gap?





--
Sent from: http://beremiz-devel.2374573.n4.nabble.com/

------------------------------------------------------------------------------
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] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
On 18-01-23 02:45, [hidden email] wrote:

> Hi,
> Thanks your reply.
> I have learned about some other plc tools,such as multiprog and codesys.
> And I have test the benchmark of mulitprog and codesys
>
> 1000 line BOOL IL test ,the result as follows:
>
> multiprog:3-4us
> codesys:2-3us
> beremiz:200us
>
> The gap is clearly , so I doubt the output file is real machine code ,cpu's
> instructon list code.
>
> Not the the middle code which runtime to analysis and to execute
>
If you doubt, you can look at it. ;-)
It's open source, nothing is hidden behind the doors.


> so ,what's the real reason of the so big gap?
It's hard to say, there could be many reasons for that. Hardware performance, [RT]OS
configuration, compiler optimization, test project difference, wrong
assumption in test suite.
Could you post your Beremiz test project?
What platform (hardware and software) do you use for your test?

--
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] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
Hi

The multiprog ,codesys and beremiz have the same test-platform RaspberryPi2
B .
The test code are the same, and the follow is tested on beremiz
Perfornance.rar
<http://beremiz-devel.2374573.n4.nabble.com/file/t13/Perfornance.rar>  




--
Sent from: http://beremiz-devel.2374573.n4.nabble.com/

------------------------------------------------------------------------------
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] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
On 18-01-23 13:08, [hidden email] wrote:

> On 18-01-23 02:45, [hidden email] wrote:
> > Hi,
> > Thanks your reply.
> > I have learned about some other plc tools,such as multiprog and codesys.
> > And I have test the benchmark of mulitprog and codesys
> >
> > 1000 line BOOL IL test ,the result as follows:
> >
> > multiprog:3-4us
> > codesys:2-3us
> > beremiz:200us
> >
> > The gap is clearly , so I doubt the output file is real machine code ,cpu's
> > instructon list code.
> >
> > Not the the middle code which runtime to analysis and to execute
> >
> If you doubt, you can look at it. ;-)
> It's open source, nothing is hidden behind the doors.
>
>
> > so ,what's the real reason of the so big gap?
> It's hard to say, there could be many reasons for that. Hardware performance, [RT]OS
> configuration, compiler optimization, test project difference, wrong
> assumption in test suite.
> Could you post your Beremiz test project?
> What platform (hardware and software) do you use for your test?
Hi  Wumengkui,

thanks for bringing this topic up.
First your code doesn't have any IL code. If you would rewrite this in
IL, then performance would be much better. Because IL is much more
lightweight that other languages and is better optimized by compiler.
For example on my desktop machine: (i7-6700k) with your test I've got
11us and for the same logic written in IL I've got 0.025us. It's
almost 500 times boost.
This is because GNU C compiler (GCC) is smart enough to optimize out all
useless code duplication to get the same results. This is one thing.

Second, as I said compiler optimization level matters. Default
optimization level in GCC is -O0 (no optimization).
You can read more about optimization levels at [1].
You can set your own optimization level in CFLAGS in project properties.
I change default optimization level for Beremiz to -O2 in the future.
It should be save, get much better performance and can be overwritten
by user's CFLAGS.

I've tested performance different on two platforms:
- desktop amd64 with i7-6700k stock clocks;
- Beaglebone Black (BBB), ARM Cortex-A8, 600Mhz.

1) AMD64 (gcc 7.2.0)
-O0 (default): 11us
-O2:           4us (2.75 faster)

2) ARM (gcc 4.6.3)
-O0 (default): 273us
-O2:           142us (1.92 faster)

As you see I've used pretty old gcc on BBB. Most likely newer gcc
would give better results. It usually does.

Third, FBD/SFC/LD generates pretty heavy code now (some of problems
could be addressed in Beremiz). FBD/SFC/LD are converted into ST code.
You may look at generated code, where is button on the toolbar for
that. So you are actually testing performance of ST, not IL.
If you look at generated C code, you look that code for every AND and OR block
has implicit EN/ENO inputs and are implemented as functions with variable
number of arguments [2] (what a great feature that you may look at the code. ;-)).
GCC will not inline functions with variable number of arguments, as a
result we have function call overhead, variable arguments handling and
gcc don't have opportunity to aggressively optimize inlined code.
This causes pretty big overhead to execute single OR/AND instruction
like in your case. To address this I wrote patch for matiec, that
addresses this case. For OR/AND/ADD/MUL/XOR it generates
special functions for up to 8 arguments (number maybe changed) and for
more arguments old function with variable number of arguments is used.
These new special functions with fixed number of arguments can be
inlined and further optimization maybe done. The patch is attached.
No GCC specific tricks are used, so theoretically it should work fine
with any C99 compiler.

Here are my results:

1) AMD64 (gcc 7.2.0)
-O0 (default): 11us
-O2:           4us (2.75 faster)
-O2 + patch:   2.5us (4.4 times faster)

2) ARM (gcc 4.6.3)
-O0 (default): 273us
-O2:           142us (1.92 faster)
-O2 + patch:   39us (7 times faster)

Wumengkui, your target (RPi2B) is running 1000Mhz instead of 600Mhz on
BBB. I think you should get with this patch around 23us and maybe even
slightly better with newer compiler.

Mario, does it make sense to apply this patch to your repo?
Additionally I attached test project for Beremiz, where I've tested all changed functions.

1. https://gcc.gnu.org/onlinedocs/gnat_ugn/Optimization-Levels.html
2. https://bitbucket.org/mjsousa/matiec/src/29735e347716b5f2da0591b0d0af0505c126aa7d/lib/C/iec_std_functions.h?at=default&fileviewer=file-view-default#iec_std_functions.h-490

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

std_function_performance.patch (23K) Download Attachment
test_arith_expand.tar.bz2 (3K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
On Wednesday, January 31, 2018 13:33:18 Andrey Skvortsov wrote:
> On 18-01-23 13:08, [hidden email] wrote:
> > On 18-01-23 02:45, [hidden email] wrote:
> > > Hi,
>
> Hi  Wumengkui,
>
> thanks for bringing this topic up.

 Yep! We have been mostly focusing on getting things to work. Optimisation
comes later. I guess the 'later' has now arrived ;-)


 Andrey, since you have the setup running, could you perhaps check the impact
of using "matiec -e" on the timings?

>
> Mario, does it make sense to apply this patch to your repo?
> Additionally I attached test project for Beremiz, where I've tested all
> changed functions.
>


 Interesting hack!

 The only downside I see is the hard-coded limit of 199 input parameters. I
find this aspect rather ugly. If somebody has some automatically generated code
that is to be compiled by matiec it would be easy to go over this limit. At
the very least I think we should expand the limit. What do you think? Any
suggestions?

 I would personally have gone for a new intermediate optimization phase in
matiec itself (replacing function calls for the equivalent ST expression), but
then we would have another limitation that it could only be applied to
function calls where no output variable was connected to the ENO output.


 Andrey:
1)
 Did you check that the patch works with "matiec -e", i.e. when the EN/ENO
parameters are removed to make the code execute faster?


2)
 It seems to me that you forgot the possibility that these functions may be
called with a single parameter "a := ADD(42);"
 This is easy to fix.

3)
 Is there any reason you explicitly defined each variation of the functions
example:
+#define OR_BYTE(...)
+#define OR_WORD(...)
+#define OR_DWORD(...)
+#define OR_LWORD(...)

 instead of adding it to the _iec macro so it gets automatically expanded by
the __ANY_NBIT (or equivalent) macro?

 #define __iec_(TYPENAME) \
 ...
 __ANY_NBIT(__iec_)
 #undef __iec_



 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] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
On 18-01-31 19:28, [hidden email] wrote:

> On Wednesday, January 31, 2018 13:33:18 Andrey Skvortsov wrote:
> > On 18-01-23 13:08, [hidden email] wrote:
> > > On 18-01-23 02:45, [hidden email] wrote:
> > > > Hi,
> >
> > Hi  Wumengkui,
> >
> > thanks for bringing this topic up.
>
>  Yep! We have been mostly focusing on getting things to work. Optimisation
> comes later. I guess the 'later' has now arrived ;-)
>
>
>  Andrey, since you have the setup running, could you perhaps check the impact
> of using "matiec -e" on the timings?

Amd64, i6700k, 4200MHz, GNU/Linux (non-RT kernel), gcc 7.2.0

-------------------------------------
 Optimization   | EN/ENO |no EN/ENO |
-------------------------------------
default         |   11   |    9.5   |
-O3        |    3.9 |    5.2   |
-O2        |    4   |    4.8   |
-Os        |    4.1 |    3.5   |
-Ofast        |    3.9 |    5.2   |
-------------------------------------
-O3    + patch  |    2.5 |    2.5   |
-O2    + patch  |    2.5 |    2.5   |
-Os    + patch  |    2.5 |    2.5   |
-Ofast + patch  |    2.5 |    2.5   |
-------------------------------------

with patch performance difference is
hardly measurable on amd64.


ARM, BBB Cortex-A8, 600Mhz, GNU/Linux, gcc 4.6.3

-------------------------------------
 Optimization   | EN/ENO |no EN/ENO |
-------------------------------------
default         |  273   |  226     |
-O3        |  141.8 |  106.2   |
-O2        |  142   |  107     |
-Os        |  152.5 |  112.2   |
-Ofast        |  141.7 |  106.2   |
-------------------------------------
-O3    + patch  |   41.6 |   38.7   |
-O2    + patch  |   39   |   38.8   |
-Os    + patch  |   78.8 |   78.8   |
-Ofast + patch  |   41.6 |   38.7   |
-------------------------------------

For embedded systems with size constaints (like Cortex-Mx, AVR and so
on) I usually use -Os. It gets pretty good results, but the code may
run slower (as in case with ARM target).
For GNU/Linux-based systems -O2 is usually a good choice, as you see
the test results.



> > Mario, does it make sense to apply this patch to your repo?
> > Additionally I attached test project for Beremiz, where I've tested all
> > changed functions.
> >
>
>
>  Interesting hack!
>
>  The only downside I see is the hard-coded limit of 199 input parameters. I
> find this aspect rather ugly. If somebody has some automatically generated code
> that is to be compiled by matiec it would be easy to go over this limit. At
> the very least I think we should expand the limit. What do you think? Any
> suggestions?
I agree and me don't like hard-coded limit either. But it was the only
way I could find to solve this problem.
Expanding the limit is not a problem at all. The patch contains Lisp
code for Emacs editor to generate these defines.
Change limit, select and evaluate lisp code.

Another solution would be that matiec would generate different
function calls for functions with small number of arguments and all
other. Like AND__BOOL__BOOL() and AND__BOOL__BOOL_VAR().
So this would help to get rid of these 199 defines. I don't now how
difficult or not-pretty this would be matiec's code.

>  I would personally have gone for a new intermediate optimization phase in
> matiec itself (replacing function calls for the equivalent ST expression), but
> then we would have another limitation that it could only be applied to
> function calls where no output variable was connected to the ENO output.
I thought about that too. This could be addressed in Beremiz as well, but
I've not investigated yet how invasive this fix would be for Beremiz.
This approach solves only part of the problem and in a different way.
I think both approaches may coexist for better end result.

>  Andrey:
> 1)
>  Did you check that the patch works with "matiec -e", i.e. when the EN/ENO
> parameters are removed to make the code execute faster?
Yes, it works. See results above.

>
> 2)
>  It seems to me that you forgot the possibility that these functions may be
> called with a single parameter "a := ADD(42);"
>  This is easy to fix.
Thanks. I didn't even know that it was allowed. Fixed and updated test
project. Both are attached.

> 3)
>  Is there any reason you explicitly defined each variation of the functions
> example:
> +#define OR_BYTE(...)
> +#define OR_WORD(...)
> +#define OR_DWORD(...)
> +#define OR_LWORD(...)
>
>  instead of adding it to the _iec macro so it gets automatically expanded by
> the __ANY_NBIT (or equivalent) macro?
>
>  #define __iec_(TYPENAME) \
>  ...
>  __ANY_NBIT(__iec_)
>  #undef __iec_
>
The reason is C preprocessor limitation.
It's not allowed to have preprocessor directives inside #define.
So I can't generate new macros with __arith_expand(), only C functions.
And OR__BYTE(...) should be macro function to do all these
preprocessor tricks with arguments.
If you have another suggestion how to solve this, I'd be very glad to
know. =)


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

improve_functions_perf.patch (23K) Download Attachment
test_arith_expand.tar.bz2 (3K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Beremiz-devel] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
On Thursday, February 01, 2018 16:40:20 [hidden email]
wrote:

> On 18-01-31 19:28, [hidden email] wrote:
> > On Wednesday, January 31, 2018 13:33:18 Andrey Skvortsov wrote:
> > > On 18-01-23 13:08, [hidden email] wrote:
> > > > On 18-01-23 02:45, [hidden email] wrote:
> > > > > Hi,
> > >
> > > Hi  Wumengkui,
> > >
> > > thanks for bringing this topic up.
> >  
> >  Yep! We have been mostly focusing on getting things to work. Optimisation
> >
> > comes later. I guess the 'later' has now arrived ;-)
> >
> >  Andrey, since you have the setup running, could you perhaps check the
> >  impact>
> > of using "matiec -e" on the timings?
>
(...)
>
> For embedded systems with size constaints (like Cortex-Mx, AVR and so
> on) I usually use -Os. It gets pretty good results, but the code may
> run slower (as in case with ARM target).
> For GNU/Linux-based systems -O2 is usually a good choice, as you see
> the test results.
>


 Thanks Andrey, that was really interesting.


> > > Mario, does it make sense to apply this patch to your repo?
> > > Additionally I attached test project for Beremiz, where I've tested all
> > > changed functions.
> >  
> >  Interesting hack!
> >  
> >  The only downside I see is the hard-coded limit of 199 input parameters.
> >  I
> >
> > find this aspect rather ugly. If somebody has some automatically generated
> > code that is to be compiled by matiec it would be easy to go over this
> > limit. At the very least I think we should expand the limit. What do you
> > think? Any suggestions?
>
> I agree and me don't like hard-coded limit either. But it was the only
> way I could find to solve this problem.

 Yep. I can't think of any other way either.

> Expanding the limit is not a problem at all. The patch contains Lisp
> code for Emacs editor to generate these defines.
> Change limit, select and evaluate lisp code.

 Yes, I noticed.

 I think:
  -   100 is too little.
 - 10 000 is too much.

 I would be fine with 1000, but it seems crazy to have 1000 lines of code in
that library file.
 
 What the heck, I seem to have changed my own mind. I'm OK leaving it at 199
for now.



>
> Another solution would be that matiec would generate different
> function calls for functions with small number of arguments and all
> other. Like AND__BOOL__BOOL() and AND__BOOL__BOOL_VAR().
> So this would help to get rid of these 199 defines. I don't now how
> difficult or not-pretty this would be matiec's code.
>

 I considered this too, and don't really like it.
 1 - the cut-off value between AND__BOOL__BOOL_XX() and
       AND__BOOL__BOOL_VAR() would need to be hard-coded in the library
       and matiec itself. These values would also need to match.
       This would be a hassle.
  2 - Additionally, not all extensible functions are getting this treatment,
        so the list of functions where the function call gets changed would
        also need to be hard-coded, and match the library implementation
        (e.g., we would change ADD(), but not MUX() )
        Really ugly!!


 Too many special cases. I would give this a pass for now, especially
considering this part of matiec needs to be cleaned up (currently has 3 copies
of (almost?) identical code in 3 different places).

 Even so, I think in the long run I would still prefer this to the hard-coded
limit to the number of function parameters. As long as everything is well
commented and explained, it should be OK.


> >  I would personally have gone for a new intermediate optimization phase in
> >
> > matiec itself (replacing function calls for the equivalent ST expression),
> > but then we would have another limitation that it could only be applied
> > to function calls where no output variable was connected to the ENO
> > output.
> I thought about that too. This could be addressed in Beremiz as well, but
> I've not investigated yet how invasive this fix would be for Beremiz.
> This approach solves only part of the problem and in a different way.

 If we do implement it, I say it should be done in matiec.
 This way standard ST and IL code gets optimized too, and not only LD and FBD.
 (unless you are suggesting beremiz change the ST and IL code too?)

 It would not really be invasive in matiec. Simply a new visitor that gets
called to do optimization. One more pass. It integrates neatly into matiec
architecture.




   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] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
Hi Mario,

On 18-02-01 17:17, [hidden email] wrote:

> > >  Interesting hack!
> > >  
> > >  The only downside I see is the hard-coded limit of 199 input parameters.
> > >  I
> > >
> > > find this aspect rather ugly. If somebody has some automatically generated
> > > code that is to be compiled by matiec it would be easy to go over this
> > > limit. At the very least I think we should expand the limit. What do you
> > > think? Any suggestions?
> >
> > I agree and me don't like hard-coded limit either. But it was the only
> > way I could find to solve this problem.
>
>  Yep. I can't think of any other way either.
>
> > Expanding the limit is not a problem at all. The patch contains Lisp
> > code for Emacs editor to generate these defines.
> > Change limit, select and evaluate lisp code.
>
>  Yes, I noticed.
>
>  I think:
>   -   100 is too little.
>  - 10 000 is too much.
>
>  I would be fine with 1000, but it seems crazy to have 1000 lines of code in
> that library file.
>  
>  What the heck, I seem to have changed my own mind. I'm OK leaving it at 199
> for now.
>
I'm OK with any number you OK with. Originally I thought about 1000 as
well, but I didn't want to scary people with so many defines in the
proposed patch.

What about number of inline functions? Is 8 OK or should be increase
the number?


> > >  I would personally have gone for a new intermediate optimization phase in
> > >
> > > matiec itself (replacing function calls for the equivalent ST expression),
> > > but then we would have another limitation that it could only be applied
> > > to function calls where no output variable was connected to the ENO
> > > output.
> > I thought about that too. This could be addressed in Beremiz as well, but
> > I've not investigated yet how invasive this fix would be for Beremiz.
> > This approach solves only part of the problem and in a different way.
>
>  If we do implement it, I say it should be done in matiec.
>  This way standard ST and IL code gets optimized too, and not only LD and FBD.
>  (unless you are suggesting beremiz change the ST and IL code too?)
>
>  It would not really be invasive in matiec. Simply a new visitor that gets
> called to do optimization. One more pass. It integrates neatly into matiec
> architecture.
>
Agree. matiec solution would be better here.


--
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] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
Hi,
The benchmark of yours is really fascinating.So I test it follow your way.
Before, I though using the FBD/LD/ST/IL , the middle file of ST is nearly
same by matiec.
Now, I use the real IL language to get the real answer. And I using -O2 to
optimize the gcc, and using patch to optimize the matiec. The benchmark as
follows:
          FBD:200us
            IL:78us
          -O2:26us
-O2+patch:0.7us
Wow,wow, the benchmark is really crazy,especially the patch function.
But when using the patch, my timer TON in the project works not
well,refering to the attchment
Performance_IL_TON.rar
<http://beremiz-devel.2374573.n4.nabble.com/file/t13/Performance_IL_TON.rar>  
So I changed another way to get the benchmark,refering to the attachment
Performance_IL_New.rar
<http://beremiz-devel.2374573.n4.nabble.com/file/t13/Performance_IL_New.rar>  




--
Sent from: http://beremiz-devel.2374573.n4.nabble.com/

------------------------------------------------------------------------------
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] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
On 18-02-02 19:59, [hidden email] wrote:

> Hi,
> The benchmark of yours is really fascinating.So I test it follow your way.
> Before, I though using the FBD/LD/ST/IL , the middle file of ST is nearly
> same by matiec.
> Now, I use the real IL language to get the real answer. And I using -O2 to
> optimize the gcc, and using patch to optimize the matiec. The benchmark as
> follows:
>           FBD:200us
>             IL:78us
>           -O2:26us
> -O2+patch:0.7us
> Wow,wow, the benchmark is really crazy,especially the patch function.
> But when using the patch, my timer TON in the project works not
> well,refering to the attchment
> Performance_IL_TON.rar
> <http://beremiz-devel.2374573.n4.nabble.com/file/t13/Performance_IL_TON.rar>  
> So I changed another way to get the benchmark,refering to the attachment
> Performance_IL_New.rar
> <http://beremiz-devel.2374573.n4.nabble.com/file/t13/Performance_IL_New.rar>  
Sure your example breaks, I've told you about this in my first answer.
In your example Performance_IL_TON you rely on changing timer's ET output during the
cycle. But it's not the case. __CURRENT_TIME used by all software timers is
updated between PLC cycles.

Therefore I've suggested to use own function
block that on GNU/Linux-based targets synchronously read current
system time.

BTW why you wrote your own wrapper for standard TON timer?

--
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] The output file of beremiz is real machine code????

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

there is problem with arithmetic functions, when ENO output is used.

For the test program
[-------- test_program.st -----------]
PROGRAM program0
  VAR
    EnOut : BOOL;
    Res : BOOL;
  END_VAR

  Res  := AND(EN := TRUE, IN1 := TRUE, ENO => EnOut);
END_PROGRAM


CONFIGURATION config

  RESOURCE resource1 ON PLC
    TASK task0(INTERVAL := T#20ms,PRIORITY := 0);
    PROGRAM instance0 WITH task0 : program0;
  END_RESOURCE
END_CONFIGURATION
[-------------------]

Matiec generates following C code

[------------ POUS.c --------------------]
static inline BOOL __PROGRAM0_AND__BOOL__BOOL1(BOOL EN,
  UINT __PARAM_COUNT,
  BOOL IN1,
  PROGRAM0 *data__)
{
  BOOL __res;
  BOOL __TMP_ENO = __GET_VAR(data__->ENOUT,);
  __res = AND__BOOL__BOOL(EN,
    &__TMP_ENO,
    __PARAM_COUNT,
    IN1);
  __SET_VAR(,data__->ENOUT,,__TMP_ENO);
  return __res;
}

void PROGRAM0_init__(PROGRAM0 *data__, BOOL retain) {
  __INIT_VAR(data__->ENOUT,__BOOL_LITERAL(FALSE),retain)
  __INIT_VAR(data__->RES,__BOOL_LITERAL(FALSE),retain)
}

// Code part
void PROGRAM0_body__(PROGRAM0 *data__) {
  // Initialise TEMP variables

  __SET_VAR(data__->,RES,,__PROGRAM0_AND__BOOL__BOOL1(
    (BOOL)__BOOL_LITERAL(TRUE),
    (UINT)1,
    (BOOL)__BOOL_LITERAL(TRUE),
    data__));

  goto __end;

__end:
  return;
} // PROGRAM0_body__()
[----------------------------------------]

It generates static inline function with __PARAM_COUNT as an argument.
Because AND__BOOL__BOOL macro receive variable in __PARAM_COUNT field,
macro-expansion doesn't work and there is compilation error.

Is it possible to get rid of __PARAM_COUNT argument, because number of
arguments is constant anyway? That would fix this problem.

--
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] The output file of beremiz is real machine code????

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


 Hi Andrey,


I know you know this, but for other interested parties:
 -- this issue is related to the latest changes to make the code execute
faster.



Regarding the issue:
> It generates static inline function with __PARAM_COUNT as an argument.
> Because AND__BOOL__BOOL macro receive variable in __PARAM_COUNT field,
> macro-expansion doesn't work and there is compilation error.
>
> Is it possible to get rid of __PARAM_COUNT argument, because number of
> arguments is constant anyway? That would fix this problem.

  The bug is not due to the  __PARAM_COUNT itself. The macro is expecting that
parameter. The problem is that the macro expects a constant preceded by a cast
 (UINT)1

 Since there is no cast, the macro is getting confused.

 I see two solutions:
1)
 get rid of the (UINT) cast
  (when calling with constant, as well as in the macro)

2)
 add an (UINT) cast when calling with parameter
  (UINT)__PARAM_COUNT



 I think (1) is preferable since it is basically deleting code from the macro,
as well as the compiler.


    Mario.




On Thursday, March 01, 2018 15:39:31 Andrey Skvortsov wrote:

> Hi Mario,
>
> there is problem with arithmetic functions, when ENO output is used.
>
> For the test program
> [-------- test_program.st -----------]
> PROGRAM program0
>   VAR
>     EnOut : BOOL;
>     Res : BOOL;
>   END_VAR
>
>   Res  := AND(EN := TRUE, IN1 := TRUE, ENO => EnOut);
> END_PROGRAM
>
>
> CONFIGURATION config
>
>   RESOURCE resource1 ON PLC
>     TASK task0(INTERVAL := T#20ms,PRIORITY := 0);
>     PROGRAM instance0 WITH task0 : program0;
>   END_RESOURCE
> END_CONFIGURATION
> [-------------------]
>
> Matiec generates following C code
>
> [------------ POUS.c --------------------]
> static inline BOOL __PROGRAM0_AND__BOOL__BOOL1(BOOL EN,
>   UINT __PARAM_COUNT,
>   BOOL IN1,
>   PROGRAM0 *data__)
> {
>   BOOL __res;
>   BOOL __TMP_ENO = __GET_VAR(data__->ENOUT,);
>   __res = AND__BOOL__BOOL(EN,
>     &__TMP_ENO,
>     __PARAM_COUNT,
>     IN1);
>   __SET_VAR(,data__->ENOUT,,__TMP_ENO);
>   return __res;
> }
>
> void PROGRAM0_init__(PROGRAM0 *data__, BOOL retain) {
>   __INIT_VAR(data__->ENOUT,__BOOL_LITERAL(FALSE),retain)
>   __INIT_VAR(data__->RES,__BOOL_LITERAL(FALSE),retain)
> }
>
> // Code part
> void PROGRAM0_body__(PROGRAM0 *data__) {
>   // Initialise TEMP variables
>
>   __SET_VAR(data__->,RES,,__PROGRAM0_AND__BOOL__BOOL1(
>     (BOOL)__BOOL_LITERAL(TRUE),
>     (UINT)1,
>     (BOOL)__BOOL_LITERAL(TRUE),
>     data__));
>
>   goto __end;
>
> __end:
>   return;
> } // PROGRAM0_body__()
> [----------------------------------------]
>
> It generates static inline function with __PARAM_COUNT as an argument.
> Because AND__BOOL__BOOL macro receive variable in __PARAM_COUNT field,
> macro-expansion doesn't work and there is compilation error.
>
> Is it possible to get rid of __PARAM_COUNT argument, because number of
> arguments is constant anyway? That would fix this problem.


------------------------------------------------------------------------------
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] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
On 18-03-01 17:08, Mario de Sousa wrote:

>
>
>  Hi Andrey,
>
>
> I know you know this, but for other interested parties:
>  -- this issue is related to the latest changes to make the code execute
> faster.
>
>
>
> Regarding the issue:
> > It generates static inline function with __PARAM_COUNT as an argument.
> > Because AND__BOOL__BOOL macro receive variable in __PARAM_COUNT field,
> > macro-expansion doesn't work and there is compilation error.
> >
> > Is it possible to get rid of __PARAM_COUNT argument, because number of
> > arguments is constant anyway? That would fix this problem.
>
>   The bug is not due to the  __PARAM_COUNT itself. The macro is expecting that
> parameter. The problem is that the macro expects a constant preceded by a cast
>  (UINT)1
>
>  Since there is no cast, the macro is getting confused.
>
>  I see two solutions:
> 1)
>  get rid of the (UINT) cast
>   (when calling with constant, as well as in the macro)
>
> 2)
>  add an (UINT) cast when calling with parameter
>   (UINT)__PARAM_COUNT
>
>
>  I think (1) is preferable since it is basically deleting code from the macro,
> as well as the compiler.
>
>

Yes, the macro is expanded, but not to correct C code. I don't
think that any of suggested solution will work.

matiec generates static inline C function with a parameter
__PARAM_COUNT (see code below).
Because it is a C function,  __PARAM_COUNT will not be replaced with
'(UINT)1'.
macro expects constant value in the field, but it gets variable
__PARAM_COUNT.

If we get rid of the (UINT) cast, then we could rewrite macro to
handle __PARAM_COUNT in the argument and expand it to implementation
with variable number of arguments. But in this case we will not get
any performance improvements.

I see that this code is generated by generate_inline()
[stage4/generate_c_inlinefcall.cc:91]. I think it would be nice if any
argument is a constant value, then it would be not passed as an
argument to generated function, but it will be embedded directly into
it.

For example, instead of

[---------------- current generated code ------------]
static inline BOOL __PROGRAM0_AND__BOOL__BOOL1(BOOL EN,
   UINT __PARAM_COUNT,
   BOOL IN1,
   PROGRAM0 *data__)
{
   BOOL __res;
   BOOL __TMP_ENO = __GET_VAR(data__->ENOUT,);
   __res = AND__BOOL__BOOL(EN,
     &__TMP_ENO,
     __PARAM_COUNT,
     IN1);
   __SET_VAR(,data__->ENOUT,,__TMP_ENO);
   return __res;
}
[----------------------------------------------------]

to have this

[---------------- current generated code ------------]
static inline BOOL __PROGRAM0_AND__BOOL__BOOL1(PROGRAM0 *data__)
{
   BOOL __res;
   BOOL __TMP_ENO = __GET_VAR(data__->ENOUT,);
   __res = AND__BOOL__BOOL((BOOL)__BOOL_LITERAL(TRUE)
     &__TMP_ENO,
     (UINT)1,
     (BOOL)__BOOL_LITERAL(TRUE);
   __SET_VAR(,data__->ENOUT,,__TMP_ENO);
   return __res;
}

[----------------------------------------------------]


This would bring benefit to all functions generated in such way even
if function will not be inlined.

>
> On Thursday, March 01, 2018 15:39:31 Andrey Skvortsov wrote:
> > Hi Mario,
> >
> > there is problem with arithmetic functions, when ENO output is used.
> >
> > For the test program
> > [-------- test_program.st -----------]
> > PROGRAM program0
> >   VAR
> >     EnOut : BOOL;
> >     Res : BOOL;
> >   END_VAR
> >
> >   Res  := AND(EN := TRUE, IN1 := TRUE, ENO => EnOut);
> > END_PROGRAM
> >
> >
> > CONFIGURATION config
> >
> >   RESOURCE resource1 ON PLC
> >     TASK task0(INTERVAL := T#20ms,PRIORITY := 0);
> >     PROGRAM instance0 WITH task0 : program0;
> >   END_RESOURCE
> > END_CONFIGURATION
> > [-------------------]
> >
> > Matiec generates following C code
> >
> > [------------ POUS.c --------------------]
> > static inline BOOL __PROGRAM0_AND__BOOL__BOOL1(BOOL EN,
> >   UINT __PARAM_COUNT,
> >   BOOL IN1,
> >   PROGRAM0 *data__)
> > {
> >   BOOL __res;
> >   BOOL __TMP_ENO = __GET_VAR(data__->ENOUT,);
> >   __res = AND__BOOL__BOOL(EN,
> >     &__TMP_ENO,
> >     __PARAM_COUNT,
> >     IN1);
> >   __SET_VAR(,data__->ENOUT,,__TMP_ENO);
> >   return __res;
> > }
> >
> > void PROGRAM0_init__(PROGRAM0 *data__, BOOL retain) {
> >   __INIT_VAR(data__->ENOUT,__BOOL_LITERAL(FALSE),retain)
> >   __INIT_VAR(data__->RES,__BOOL_LITERAL(FALSE),retain)
> > }
> >
> > // Code part
> > void PROGRAM0_body__(PROGRAM0 *data__) {
> >   // Initialise TEMP variables
> >
> >   __SET_VAR(data__->,RES,,__PROGRAM0_AND__BOOL__BOOL1(
> >     (BOOL)__BOOL_LITERAL(TRUE),
> >     (UINT)1,
> >     (BOOL)__BOOL_LITERAL(TRUE),
> >     data__));
> >
> >   goto __end;
> >
> > __end:
> >   return;
> > } // PROGRAM0_body__()
> > [----------------------------------------]
> >
> > It generates static inline function with __PARAM_COUNT as an argument.
> > Because AND__BOOL__BOOL macro receive variable in __PARAM_COUNT field,
> > macro-expansion doesn't work and there is compilation error.
> >
> > Is it possible to get rid of __PARAM_COUNT argument, because number of
> > arguments is constant anyway? That would fix this problem.
>
--
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] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
On Thursday, March 01, 2018 21:30:46 [hidden email]
wrote:

> On 18-03-01 17:08, Mario de Sousa wrote:
> >  Hi Andrey,
> >
> > I know you know this, but for other interested parties:
> >  -- this issue is related to the latest changes to make the code execute
> >
> > faster.
> >
> > Regarding the issue:
> > > It generates static inline function with __PARAM_COUNT as an argument.
> > > Because AND__BOOL__BOOL macro receive variable in __PARAM_COUNT field,
> > > macro-expansion doesn't work and there is compilation error.
> > >
> > > Is it possible to get rid of __PARAM_COUNT argument, because number of
> > > arguments is constant anyway? That would fix this problem.
> > >
> >   The bug is not due to the  __PARAM_COUNT itself. The macro is expecting
> >   that>
> > parameter. The problem is that the macro expects a constant preceded by a
> > cast>
> >  (UINT)1
> >  
> >  Since there is no cast, the macro is getting confused.
> >
> >  I see two solutions:
> > 1)
> >
> >  get rid of the (UINT) cast
> >  
> >   (when calling with constant, as well as in the macro)
> >
> > 2)
> >
> >  add an (UINT) cast when calling with parameter
> >  
> >   (UINT)__PARAM_COUNT
> >  
> >  I think (1) is preferable since it is basically deleting code from the
> >  macro,>
> > as well as the compiler.
>
> Yes, the macro is expanded, but not to correct C code. I don't
> think that any of suggested solution will work.

 Yes, you are correct.
 The macro expansion requires a constant...



>
> I see that this code is generated by generate_inline()
> [stage4/generate_c_inlinefcall.cc:91]. I think it would be nice if any
> argument is a constant value, then it would be not passed as an
> argument to generated function, but it will be embedded directly into
> it.
>
> For example, instead of
>
> [---------------- current generated code ------------]
> static inline BOOL __PROGRAM0_AND__BOOL__BOOL1(BOOL EN,
>    UINT __PARAM_COUNT,
>    BOOL IN1,
>    PROGRAM0 *data__)
> {
>    BOOL __res;
>    BOOL __TMP_ENO = __GET_VAR(data__->ENOUT,);
>    __res = AND__BOOL__BOOL(EN,
>      &__TMP_ENO,
>      __PARAM_COUNT,
>      IN1);
>    __SET_VAR(,data__->ENOUT,,__TMP_ENO);
>    return __res;
> }
> [----------------------------------------------------]
>
> to have this
>
> [---------------- current generated code ------------]
> static inline BOOL __PROGRAM0_AND__BOOL__BOOL1(PROGRAM0 *data__)
> {
>    BOOL __res;
>    BOOL __TMP_ENO = __GET_VAR(data__->ENOUT,);
>    __res = AND__BOOL__BOOL((BOOL)__BOOL_LITERAL(TRUE)
>      &__TMP_ENO,
>      (UINT)1,
>      (BOOL)__BOOL_LITERAL(TRUE);
>    __SET_VAR(,data__->ENOUT,,__TMP_ENO);
>    return __res;
> }
>
> [----------------------------------------------------]
>
>



 I think it would be easier to do it to ALL parameters, even if they are not
constant, than to do it only for the constant parameters.



 (I actually don't like the stage4/generate_c_inlinefcall.cc approach at all,
as I think we could do without it completely if beremiz had gone with a
different strategy for overloading of variables. But changing that would imply
changes to beremiz too, so I have never bothered to fix this).


 I have been thinking for a few minutes trying to decide if this change would
result in simpler or more complex code for stage4/generate_c_inlinefcall.cc,
but have yet to reach a conclusion.. Too many scenarios and changes I would
like to do if I start messing with this code..


   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] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
Hi Mario,

On 18-03-01 19:24, [hidden email] wrote:
> On Thursday, March 01, 2018 21:30:46 [hidden email]
> wrote:
> > On 18-03-01 17:08, Mario de Sousa wrote:
> > >  Hi Andrey,
> > >

> > > Regarding the issue:
> > > > It generates static inline function with __PARAM_COUNT as an argument.
> > > > Because AND__BOOL__BOOL macro receive variable in __PARAM_COUNT field,
> > > > macro-expansion doesn't work and there is compilation error.
> > > >
> > > > Is it possible to get rid of __PARAM_COUNT argument, because number of
> > > > arguments is constant anyway? That would fix this problem.
> > > >
> > >   The bug is not due to the  __PARAM_COUNT itself. The macro is expecting
> > >   that>
> > > parameter. The problem is that the macro expects a constant preceded by a
> > > cast>
> > >  (UINT)1
> > >  
> > >  Since there is no cast, the macro is getting confused.
> > >
> > >  I see two solutions:
> > > 1)
> > >
> > >  get rid of the (UINT) cast
> > >  
> > >   (when calling with constant, as well as in the macro)
> > >
> > > 2)
> > >
> > >  add an (UINT) cast when calling with parameter
> > >  
> > >   (UINT)__PARAM_COUNT
> > >  
> > >  I think (1) is preferable since it is basically deleting code from the
> > >  macro,>
> > > as well as the compiler.
> >
> > Yes, the macro is expanded, but not to correct C code. I don't
> > think that any of suggested solution will work.
>
>  Yes, you are correct.
>  The macro expansion requires a constant...
>
>
>
> >
> > I see that this code is generated by generate_inline()
> > [stage4/generate_c_inlinefcall.cc:91]. I think it would be nice if any
> > argument is a constant value, then it would be not passed as an
> > argument to generated function, but it will be embedded directly into
> > it.
> >
> > For example, instead of
> >
> > [---------------- current generated code ------------]
> > static inline BOOL __PROGRAM0_AND__BOOL__BOOL1(BOOL EN,
> >    UINT __PARAM_COUNT,
> >    BOOL IN1,
> >    PROGRAM0 *data__)
> > {
> >    BOOL __res;
> >    BOOL __TMP_ENO = __GET_VAR(data__->ENOUT,);
> >    __res = AND__BOOL__BOOL(EN,
> >      &__TMP_ENO,
> >      __PARAM_COUNT,
> >      IN1);
> >    __SET_VAR(,data__->ENOUT,,__TMP_ENO);
> >    return __res;
> > }
> > [----------------------------------------------------]
> >
> > to have this
> >
> > [---------------- current generated code ------------]
> > static inline BOOL __PROGRAM0_AND__BOOL__BOOL1(PROGRAM0 *data__)
> > {
> >    BOOL __res;
> >    BOOL __TMP_ENO = __GET_VAR(data__->ENOUT,);
> >    __res = AND__BOOL__BOOL((BOOL)__BOOL_LITERAL(TRUE)
> >      &__TMP_ENO,
> >      (UINT)1,
> >      (BOOL)__BOOL_LITERAL(TRUE);
> >    __SET_VAR(,data__->ENOUT,,__TMP_ENO);
> >    return __res;
> > }
> >
> > [----------------------------------------------------]
> >
> >
>
>
>
>  I think it would be easier to do it to ALL parameters, even if they are not
> constant, than to do it only for the constant parameters.
>
>
>
>  (I actually don't like the stage4/generate_c_inlinefcall.cc approach at all,
> as I think we could do without it completely if beremiz had gone with a
> different strategy for overloading of variables. But changing that would imply
> changes to beremiz too, so I have never bothered to fix this).
could you give more details why Beremiz does need changes?

>
>
>  I have been thinking for a few minutes trying to decide if this change would
> result in simpler or more complex code for stage4/generate_c_inlinefcall.cc,
> but have yet to reach a conclusion.. Too many scenarios and changes I would
> like to do if I start messing with this code..
>
>
>    Mario.

--
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] The output file of beremiz is real machine code????

Beremiz-Devel mailing list

 Hi Andrey,


 Thanks for replying. I have been meaning to go into more detail, but have
been putting it off.

On Friday, March 23, 2018 12:21:57 [hidden email] wrote:

> Hi Mario,
>
> >
> >  (I actually don't like the stage4/generate_c_inlinefcall.cc approach at
> >  all,>
> > as I think we could do without it completely if beremiz had gone with a
> > different strategy for overloading of variables. But changing that would
> > imply changes to beremiz too, so I have never bothered to fix this).
>
> could you give more details why Beremiz does need changes?
>

 There is a long chain of dependencies I would like to remove...


0) I would like to change the way forced variables are handled.


1) doing (0) would allow us to completely remove the generate_c_inlinefcall_c
code.

2) doing (0) would allow us to have a visitor for replacing the AND(), OR(),
etc.. function calls with the equivalent operators that would also be able to
handle calls that include passing an ENO parameter.

3)
 doing (2) would allow us to remove your changes to the standard lib
implementation, as they would no longer be needed.

 We would end up with:
 a) cleaner generated C code
 b) smaller matiec source code
 c) cleaner matiec source code
 d) cleaner standard lib implementation (revert to old version)



 Now to answer your question, which is basically how do I intend doing (0).

 Currently matiec creates a struct for each global variable.

typedef IEC_REAL REAL;
typedef struct { IEC_REAL value; IEC_BYTE flags;} __IEC_REAL_t;
__IEC_REAL_t  a_global_var;

 I would like to change this to:
typedef IEC_REAL REAL;
typedef struct { IEC_REAL read; IEC_REAL *write;} __IEC_REAL_t;
__IEC_REAL_t  a_global_var;

 And the variable would be initialized to  
a_global_var.read = 0;  // default initial value
a_global_var.write = &a_global_var.read;


 All read access to a_global_var would use (a_global_var.read)
 All write access to a_global_var would use (*a_global_var.write)

 Forcing the variable would involve changing the a_global_var.write pointer to
point to some memory area that would be ignored, and setting a_global_var.read
to the forced value.

 This change would result in much simpler generated C code. We would not
longer need so many variants of the GET__XXX and SET__XXX macros. This in turn
implies simpler matiec source code.


 (NOTE: I have not yet made a thorough analysis of how arrays and structs
would be handled, but my guess is that we could be able to handle them).


 Beremiz would need to be changed so it would handle the forcing of variables
using the new mechanism. My guess is that it is not much work.

 However, doing (0) to matiec will involve a lot of changes, and will result
in more elegant code but no extra functionality for the end user. So I have
been putting this off for ages.  However, with this new bug introduced by the
changes to the standrd library, I am starting to feel that we really need to
start cleaning this all up.

 What do you think?


   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] The output file of beremiz is real machine code????

Beremiz-Devel mailing list
Hi, Mario!

How about

>#define __IEC_DEBUG_FLAG 0x01
>#define __IEC_FORCE_FLAG 0x02
>#define __IEC_RETAIN_FLAG 0x04
>#define __IEC_OUTPUT_FLAG 0x08

?

How retain and other things would be handled in case of typedef change?


Best regrds,
Paul Beltyukov

2018-03-23 19:53 GMT+05:00 <[hidden email]>:

 Hi Andrey,


 Thanks for replying. I have been meaning to go into more detail, but have
been putting it off.

On Friday, March 23, 2018 12:21:57 [hidden email] wrote:
> Hi Mario,
>
> >
> >  (I actually don't like the stage4/generate_c_inlinefcall.cc approach at
> >  all,>
> > as I think we could do without it completely if beremiz had gone with a
> > different strategy for overloading of variables. But changing that would
> > imply changes to beremiz too, so I have never bothered to fix this).
>
> could you give more details why Beremiz does need changes?
>

 There is a long chain of dependencies I would like to remove...


0) I would like to change the way forced variables are handled.


1) doing (0) would allow us to completely remove the generate_c_inlinefcall_c
code.

2) doing (0) would allow us to have a visitor for replacing the AND(), OR(),
etc.. function calls with the equivalent operators that would also be able to
handle calls that include passing an ENO parameter.

3)
 doing (2) would allow us to remove your changes to the standard lib
implementation, as they would no longer be needed.

 We would end up with:
 a) cleaner generated C code
 b) smaller matiec source code
 c) cleaner matiec source code
 d) cleaner standard lib implementation (revert to old version)



 Now to answer your question, which is basically how do I intend doing (0).

 Currently matiec creates a struct for each global variable.

typedef IEC_REAL REAL;
typedef struct { IEC_REAL value; IEC_BYTE flags;} __IEC_REAL_t;
__IEC_REAL_t  a_global_var;

 I would like to change this to:
typedef IEC_REAL REAL;
typedef struct { IEC_REAL read; IEC_REAL *write;} __IEC_REAL_t;
__IEC_REAL_t  a_global_var;

 And the variable would be initialized to
a_global_var.read = 0;  // default initial value
a_global_var.write = &a_global_var.read;


 All read access to a_global_var would use (a_global_var.read)
 All write access to a_global_var would use (*a_global_var.write)

 Forcing the variable would involve changing the a_global_var.write pointer to
point to some memory area that would be ignored, and setting a_global_var.read
to the forced value.

 This change would result in much simpler generated C code. We would not
longer need so many variants of the GET__XXX and SET__XXX macros. This in turn
implies simpler matiec source code.


 (NOTE: I have not yet made a thorough analysis of how arrays and structs
would be handled, but my guess is that we could be able to handle them).


 Beremiz would need to be changed so it would handle the forcing of variables
using the new mechanism. My guess is that it is not much work.

 However, doing (0) to matiec will involve a lot of changes, and will result
in more elegant code but no extra functionality for the end user. So I have
been putting this off for ages.  However, with this new bug introduced by the
changes to the standrd library, I am starting to feel that we really need to
start cleaning this all up.

 What do you think?


   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] The output file of beremiz is real machine code????

Beremiz-Devel mailing list

 Hi Paul,

 > >#define __IEC_FORCE_FLAG 0x02

 No longer needed, as it is replaced by the pointers...


> >#define __IEC_DEBUG_FLAG 0x01
> >#define __IEC_RETAIN_FLAG 0x04
> >#define __IEC_OUTPUT_FLAG 0x08


 The simples solution is to keep them as they are.



    Mario.



On Saturday, March 24, 2018 10:27:27 [hidden email]
wrote:

> Hi, Mario!
>
> How about
>
> >#define __IEC_DEBUG_FLAG 0x01
> >#define __IEC_FORCE_FLAG 0x02
> >#define __IEC_RETAIN_FLAG 0x04
> >#define __IEC_OUTPUT_FLAG 0x08
>
> ?
>
> How retain and other things would be handled in case of typedef change?
>
>
> Best regrds,
> Paul Beltyukov
>
> 2018-03-23 19:53 GMT+05:00 <[hidden email]>:
> >  Hi Andrey,
> >  
> >  
> >  Thanks for replying. I have been meaning to go into more detail, but have
> >
> > been putting it off.
> >
> > On Friday, March 23, 2018 12:21:57 [hidden email]
> >
> > wrote:
> > > Hi Mario,
> > >
> > > >  (I actually don't like the stage4/generate_c_inlinefcall.cc approach
> >
> > at
> >
> > > >  all,>
> > > >
> > > > as I think we could do without it completely if beremiz had gone with
> > > > a
> > > > different strategy for overloading of variables. But changing that
> >
> > would
> >
> > > > imply changes to beremiz too, so I have never bothered to fix this).
> > >
> > > could you give more details why Beremiz does need changes?
> >  
> >  There is a long chain of dependencies I would like to remove...
> >
> > 0) I would like to change the way forced variables are handled.
> >
> >
> > 1) doing (0) would allow us to completely remove the
> > generate_c_inlinefcall_c
> > code.
> >
> > 2) doing (0) would allow us to have a visitor for replacing the AND(),
> > OR(),
> > etc.. function calls with the equivalent operators that would also be able
> > to
> > handle calls that include passing an ENO parameter.
> >
> > 3)
> >
> >  doing (2) would allow us to remove your changes to the standard lib
> >
> > implementation, as they would no longer be needed.
> >
> >  We would end up with:
> >  a) cleaner generated C code
> >  b) smaller matiec source code
> >  c) cleaner matiec source code
> >  d) cleaner standard lib implementation (revert to old version)
> >  
> >  
> >  
> >  Now to answer your question, which is basically how do I intend doing
> >  (0).
> >  
> >  Currently matiec creates a struct for each global variable.
> >
> > typedef IEC_REAL REAL;
> > typedef struct { IEC_REAL value; IEC_BYTE flags;} __IEC_REAL_t;
> > __IEC_REAL_t  a_global_var;
> >
> >  I would like to change this to:
> > typedef IEC_REAL REAL;
> > typedef struct { IEC_REAL read; IEC_REAL *write;} __IEC_REAL_t;
> > __IEC_REAL_t  a_global_var;
> >
> >  And the variable would be initialized to
> >
> > a_global_var.read = 0;  // default initial value
> > a_global_var.write = &a_global_var.read;
> >
> >  All read access to a_global_var would use (a_global_var.read)
> >  All write access to a_global_var would use (*a_global_var.write)
> >  
> >  Forcing the variable would involve changing the a_global_var.write
> >
> > pointer to
> > point to some memory area that would be ignored, and setting
> > a_global_var.read
> > to the forced value.
> >
> >  This change would result in much simpler generated C code. We would not
> >
> > longer need so many variants of the GET__XXX and SET__XXX macros. This in
> > turn
> > implies simpler matiec source code.
> >
> >  (NOTE: I have not yet made a thorough analysis of how arrays and structs
> >
> > would be handled, but my guess is that we could be able to handle them).
> >
> >  Beremiz would need to be changed so it would handle the forcing of
> >
> > variables
> > using the new mechanism. My guess is that it is not much work.
> >
> >  However, doing (0) to matiec will involve a lot of changes, and will
> >
> > result
> > in more elegant code but no extra functionality for the end user. So I
> > have
> > been putting this off for ages.  However, with this new bug introduced by
> > the
> > changes to the standrd library, I am starting to feel that we really need
> > to
> > start cleaning this all up.
> >
> >  What do you think?
> >  
> >    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