[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Getting involved in Bison
From: |
Morales Cayuela, Victor (NSB - CN/Hangzhou) |
Subject: |
RE: Getting involved in Bison |
Date: |
Mon, 13 Apr 2020 10:54:19 +0000 |
Hello!
First of all, I hope that all you and your relatives/friends are healthy, this
coronavirus is wreaking havoc.
I have started working on the push parser in C++. Since I feel a bit
unconfident about how it should be done, I would like you to double-check first
if all this is going the correct direction.
I have just added a few things to transform it slowly from C to C++. I have
added namespace::yy and wrapped the public functions in a class. I substituted
"static const" for "constexpr. All that was easy and worked.
The major problem I have detected is moving types and functions inside the
class (as we said, depending on the performance, we would move in variables as
well). Most of the types used in functions or arguments are generated in the cc
file, which means that we would need to move them to the hh to create a
definition (for example, yy_state_t). That would need quite a few changes,
should I proceed?
Another issue would be to substitute the "mallocs" and "frees" for "new" and
"delete" and "typedef" to "using" to get a real C++ flavor, although I agree
that it might not bring any advantages for that specific code.
Thanks a lot,
Victor
-----Original Message-----
From: Akim Demaille <address@hidden>
Sent: 2020年2月27日 2:52
To: Morales Cayuela, Victor (NSB - CN/Hangzhou) <address@hidden>
Cc: Bison Bugs <address@hidden>; Bison Patches <address@hidden>
Subject: Re: Getting involved in Bison
Hi Victor,
> Le 24 févr. 2020 à 06:40, Morales Cayuela, Victor (NSB - CN/Hangzhou)
> <address@hidden> a écrit :
>
>> Maybe you should start with that: find a means to benchmark two pull
>> parsers: one off-the-shelf, generated by today's lalr1.cc, and another one
>> where the local variables that need to be member variables in push-mode are
>> made member variables.
>
> What is the expected difference in performance between local and member
> variables?
Well, maybe there won't be any, but if there is, we should note it. It will
certainly change the locality of data, which can have really bad consequence on
the performances.
> Besides constructor creation/destruction and variable lifetime, I would say
> there should not be other issues. Anyway let's test both 😊
Yup. It's been years I stopped believing I can predict speed
improvements/regressions just by thinking. See
https://lists.gnu.org/r/bison-patches/2020-02/msg00067.html for an example of
some behavior I don't understand.
There's etc/bench which might provide some help for benching. I should
modernize it a bit. I'll send a patch soon.
> Related to this topic:
> #################
> Do you remember Akim that I told you that in my Mac tests did not pass
> completely but in yours they did? Specifically all in these categories:
> LALR(1) Calculator
> LALR(1) C++ Calculator
>
> Since this time will I need them, I decided to checked them. Seems that in
> Mac `wc -l` indents the result with the number of lines, mismatching with the
> expected pattern:
> tests/testsuite.log:
> ./calc.at:1111: grep -v 'Return for a new token:' stderr | wc -l
> --- - 2020-02-22 13:15:01.000000000 +0800
> +++
> /Users/Victor/Projects/bison/tests/testsuite.dir/at-groups/456/stdout
> 2020-02-22 13:15:01.000000000 +0800
> @@ -1,2 +1,2 @@
> -0
> + 0
> Has someone previously reported this? Seems I am predestined to deal with
> indentations XD
:) :) :)
This is unexpected: I really believed that *all* wc would not indent when fed
on stdin. I was wrong.
Try this instead:
grep -v 'Return for a new token:' stderr | grep -c .
> Separate topic about C++:
> #####################
> I believe we could improve a bit the C++ generated code and standardize it
> with modern syntax.
>
> For example, C++ does no longer recommend constructing objects with
> parenthesis, but with braces. I saw yesterday this statement:
> symbol_type yylookahead (yylex ());
> Which should be rewritten as:
> symbol_type yylookahead {yylex ()};
I'm a big fan of "almost always auto", so don't get me started on this :)
This is not valid in C++98, and so far I don't see enough compelling reason to
make the skeleton more complex just for that. I'm fine with using move
semantics when available, noexcept and the like or any other "real" feature
that modern C++s can provide us with, but I don't see the need to require C++11
just yet, and to make the skeleton more complex to just match better style in
more recent versions.
> There are also some keywords that help the compiler optimizing. For example,
> this structure has a default constructor:
> struct by_type { /* Default constructor */ by_type (); ... }
> We might add "= default" (or even "= delete" if it is not used and we prefer
> to avoid it being created without parameters):
> struct by_type { /* Default constructor */ by_type () = default; ... }
On this, I agree. Actually, I kind of committed myself to do it at some point
(https://lists.gnu.org/r/bug-bison/2019-05/msg00015.html), but you are welcome
to beat me on this :)
> We can discuss all this after the push parser.
Don't feel like you have some mandatory road-map to follow. If you want to
address these simpler tasks first or concurrently, feel free to do it!
Cheers!
Push calc C++.zip
Description: Push calc C++.zip
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- RE: Getting involved in Bison,
Morales Cayuela, Victor (NSB - CN/Hangzhou) <=