tinycc | tinycc fork : hopefully , better OSX support , EFI targets

I think something along the lines of your option 2 would be good. Except maybe to be a little easier would be to have an Expr class with a float Expr::eval(std::unordered_map vars) method. Then implement subclasses like Var with a name, Add with left and right, Sub, Mult, Div, etc all the functions you want. When evaluating you just pass in the map with like {{"x",3},{"y",4}} or whatever and each Expr object would pass that down to any subexpressions and then do it's operation.

I would think this would be reasonably fast. How complicated of expressions do you think your user's would be putting in? Most expressions probably won't require more than 10-20 function calls.

It can also get a lot faster

If you're trying to make something that graphs functions (or similar) you could speed this up considerably if you made your operations able to work with vectors of values rather than single scalar values.

Assuming you wanted to graph something like x^3 - 6x^2 + 11x - 6 with 10,000 points, if you had your Expr objects only working on single values at a time, yeah this would be like ~10-15 function calls * 10,000 points = a lot jumping around! However, if your Expr objects could take arrays of values, like calling eval with {{"x",[1,2,3...10000]}} then this would only be ~10-15 function calls, total, into optimized C++. This could easily scale up to a larger number of points and still be very fast.

The simplest is just to change the line that is used to run the static library with your custom semantics:

It was simple. In main message processing loop, i call IsDialogMessage() with proper HWND. Then, if this function returns zero, i call normal TranslateMessage and DispatchMessage functions. Here is code:

Apparently gcc emits a .section .text,"a",@progbits directive instead of just .section .text. I don't see any way to avoid it. However the default linker script usually merges all sections named .text.* so you can do something like __attribute__((section(".text.consts"))) and in the final binary it will be in the .text section.

@Clifford found a hackish workaround which involves putting a # after the section name so that the assembler considers the rest of the line a comment.

const char[3] is not compatible with char[37].

Nor is "pointer to qualified type" compatible with "pointer to type" - don't mix this up with "qualified pointer to type". (Const correctness does unfortunately not work with array pointers.)

The relevant part being the rule of simple assignment C17 6.5.16.1:

• the left operand has atomic, qualified, or unqualified pointer type, and (considering the type the left operand would have after lvalue conversion) both operands are pointers to qualified or unqualified versions of compatible types, and the type pointed to by the left has all the qualifiers of the type pointed to by the right;

Looking at various compilers:

• gcc in "gnu mode" is useless for checking C conformance. You must compile with -std=cxx -pedantic-errors. After which gcc behaves fine: gcc -std=c17 -pedantic-errors:

  error: pointers to arrays with different qualifiers are incompatible in ISO C [-Wpedantic]

• icc gives the same diagnostics as gcc, it works fine.

• Whereas clang -std=c17 -pedantic-errors does not report errors, so it apparently does not conform to the C standard.

Yacc's name is an abbreviation for "yet another compiler compiler", which strongly suggests that it was neither the first nor the second such tool.

Indeed, the Wikipedia article on History of Compiler Construction notes that

In the early 1960s, Robert McClure at Texas Instruments invented a compiler-compiler called TMG, the name taken from "transmogrification". In the following years TMG was ported to several UNIVAC and IBM mainframe computers.

…

Not long after Ken Thompson wrote the first version of Unix for the PDP-7 in 1969, Doug McIlroy created the new system's first higher-level language: an implementation of McClure's TMG. TMG was also the compiler definition tool used by Ken Thompson to write the compiler for the B language on his PDP-7 in 1970. B was the immediate ancestor of C.

That's not quite an answer to your question, but it provides some possibilities.

I wouldn't be at all surprised if Ritchie just banged together a hand-built top-down or operator precedence parser. The techniques were well-known, and the original C language presented few challenges. But parser generating tools definitely existed.

A comment on the OP by Alexey Frunze points to this early version of the C compiler. It's basically a recursive-descent top-down parser, up to the point where expressions need to be parsed at which point it uses a shunting-yard-like operator precedence grammar. (See the function tree in the first source file for the expression parser.) This style of starting with a top-down algorithm and switching to a bottom-up algorithm (such as operator-precedence) when needed is sometimes called "left corner" (LC) parsing.

So that's basically the architecture which I said wouldn't surprise me, and it didn't :).

It's worth noting that the compiler unearthed by Alexey (and also by @Torek in a comment to this post) does not handle anything close to what we generally consider the C language these days. In particular, it handles only a small subset of the declaration syntax (no structs or unions, for example), which is probably the most complicated part of the K&R C grammar. So it does not answer your question about how to produce a "simple" parser for C.

C is (mostly) parseable with an LALR(1) grammar, although you need to implement some version of the "lexer hack" in order to correctly parse cast expressions. The input to the parser (translation phase 7) will be a stream of tokens produced by the preprocessing code (translation phase 4, probably incorporating phases 5 and 6), which itself may draw upon a (f)lex tokenizer (phase 3) whose input will have been sanitized in some fashion according to phases 1 and 2. (See § 5.1.1.2 for a precise definition of the phases).

Sadly, (f)lex was not designed to be part of a pipeline; they really want to just handle the task of reading the source. However, flex can be convinced to let you provide chunks of input by redefining the YY_INPUT macro. Handling trigraphs (if you chose to do that) and line continuations can be done using a simple state machine; it's convenient that these transformations only shrink the input, simplifying handling of the maximum input length parameter to YY_INPUT. (Don't provide input one character at a time as suggested by the example in the flex manual.)

Since the preprocessor must produce a stream of tokens (at this point, whitespace is no longer important), it is convenient to use bison's push-parser interface. (Indeed, it is very often more convenient to use the push API.) If you take that suggestion, you will end up with phase 4 as the top-level driver of the parse.

You could hand-build a preprocessor-directive parser, but getting #if expressions and pragmas right suggests the use of a separate bison parser for preprocessing.

If you just want to learn how to build a compiler, you might want to start with a simpler language such as Tiger, the language used as a running example in Andrew Appel's excellent textbooks on compiler construction.

To link in a library, you need to add a -l${library_basename} flag after all c files or o files. If the library is named libtcc.a or libtcc.so (on Windows it's probably tcc.dll or libtcc.dll), you need to add -ltcc.