I'm just curious. What problems in kernel involves parsing? On Feb 2, 2018 5:01 AM, <valdis.kletni...@vt.edu> wrote:
> On Thu, 01 Feb 2018 11:37:26 -0500, Aruna Hewapathirane said: > > > Somethings are not so obvious like what could possibly be a *.y file or > > *.tc file ? If you type in find -name "*.y" in my case i see: > > > > aruna@debian:~/linux-4.15$ find -name "*.y" > > > Now if I pass that to the 'file' command ... > > > > aruna@debian:~/linux-4.15$ file `find -name "*.y"` // yes you need those > > back ticks :) > > > > ./drivers/scsi/aic7xxx/aicasm/aicasm_macro_gram.y: C source, ASCII text > > > So 'file' tells us these are C program files ? Lets verify ? If you 'cat' > > any of these files you will see it is actual C code. Why does it have a > > file extension of .y ? > > Actually, if you look more closely at it, it's *not* actually C code. The > 'file' > command makes its best guess, triggered off things like '#include', etc. > > The 'tl;dr' answer is "The *.y are input files for bison, and the *.l are > input files for flex". > > The more detailed explanation, with 50 years of computer history.... > > [/usr/src/linux-next] head -20 tools/perf/util/expr.y > /* Simple expression parser */ > %{ > #include "util.h" > #include "util/debug.h" > #define IN_EXPR_Y 1 > #include "expr.h" > #include "smt.h" > #include <string.h> > > #define MAXIDLEN 256 > %} > > %pure-parser > %parse-param { double *final_val } > %parse-param { struct parse_ctx *ctx } > %parse-param { const char **pp } > %lex-param { const char **pp } > > %union { > double num; > > That's got a bunch of % in unusual places for C, doesn't it? :) > > Let's hit the rewind button back 5 decades or so, when tools for building > programs were just becoming created. And everybody who wanted to write a > compiler for a language, or parsing data that wasn't strict 'ID is in > columns > 5-12' formatting, or a whole bunch of other stuff, had to write a parser > to do > the parsing. > > For those who have never done it, writing lexical scanners and parsers by > hand > is a thankless job. I know from experience that the parse table for an LALR > parser for Pascal ends up being essentially a spreadsheet with some 300 > rows > and 400 columns that you get to fill in by hand one at a time - and > getting one > entry wrong means you have a buggy compiler (I took Compiler Design in > college > the last year we had to do it by hand) > > The first few compiled languages (COBOL, FORTRAN, and a few others) also > had to > make do with hand-coded parsers. And then in 1958, Algol happened, and it > spawned all sorts of languages - everything from C to PL/I to Pascal and > probably 200+ others (pretty much every language that allows nested > declarations and has begin/end tokens of some sort owes it to Algol). And > the > other thing about Algol was that it was a much "bigger" language than > previous > ones, so John Backus invented a meta-language called BNF to provide a > formal > specification of the syntax. > > (For those who are curious, a EBNF specification for Pascal syntax is here: > http://www.fit.vutbr.cz/study/courses/APR/public/ebnf.html > > The interesting thing about BNF is that it has these things called > "production > rules" which define what legal programs look like - and the test for > "legal" > can be done with a parser using a software/mathematical construct called a > "finite state machine" (and the 3 of you who understand the difference > between > a context-sensitive grammar and a context-free grammar can stop giggling > right > now.. ;) > > So somebody had the bright idea that if you had a formal BNF > specification, you > could write a program that would read the BNF, and spit out the C source > for a > parser skeleton based on a finite state machine. And thus were born two > programs called 'lex' (a lexical scanner - something that reads the > source, and > outputs code that says "Hey, that's the word 'struct'" or "we just saw a > 'for"). and another called 'yacc' (Yet Another Compiler Compiler) which > did the > higher level "this is a legal function, but *that* right there is a > messed-up > 'if' statement that has a syntax error" stuff. Oh, and generate output > code, too. > > Of course, that was decades ago, and eventually somebody wrote a faster > 'lex' - > and thus was born /usr/bin/flex. And yacc needed work, so the improved > version > was, of course, called bison (think about it for a bit..) > > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > >
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies