Menu

#371 internal parser adjustments (decreasing yyparse and parser.y)

GC 3.x
accepted
5 - default
2020-07-14
2020-03-01
No

The parser (which should be nearly identical between 4.0-early-dev and 3.1-dev) should be adjusted:

  • we should extract some functions from the actual parser (generated as yyparse), to make it more easy for compilers to "optimize" it (we're currently breaking compiler default limits for HPUX for example, see [a0b1446b0c]) and may even be able to combine some code this way
  • move some/most of the called functions out of parser.y - with the current approach "many functions are static in the same source" the biggest source file needs to be recompiled even for a very simple parser adjustment and more important: even for a minor fix in the actual "code" the parser needs to be regenerated which needs additional tools (and depending on its version; which must be "relative" new with the 4.x parser; also generates quite different files).

adjusted to Edward as he worked on the parser in this area before

Related

Discussion: a0b1446b0c
Discussion: Problems to install GnuCobol 2.2 (and 3.0) on HPUX 11.31 ia64

Discussion

  • Edward Hart

    Edward Hart - 2020-07-14

    I've looked into this and can't see much to move. I've attached a patch which removes 400 lines (out of 18000) from parser.y. There are two main problems:

    1. While it is possible to move all the static functions, they use a lot of global variables. Moving these functions will be error-prone (and make the remaining code uglier).
    2. Most code in yyparse is quite minimal - around 3-5 lines per block. It's possible to remove this - we could have a strict "all validating/emitting in typeck.c/field.c" policy - but it would be a lot of effort for little gain.
     
    • Simon Sobisch

      Simon Sobisch - 2020-07-14

      Thank you for the feedback. We may should limit this to your changes + inspect if there's reason to move some of the static functions.

      I do like all of your changes but the cb_emit_statements - I think it is better to keep this part as it is (that global variable that is checked before any code emitting looks bad in any case, but as the point is "have full checks but no code emitted I don't come up with much better ways for the current define).

       

Log in to post a comment.