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..)
Attachment:
pgpfl7iuftPio.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
