Re: [Tinycc-devel] How many pases tcc doesn? Could we make a faster compiler than tcc for another language?

[Tony Papadimitriou]

Single pass is not exactly what you think.  The compiler passes over your 
code once but it keeps track of various things for later resolution.

For example, #define's are macros that are stored in some 'dictionary' to be 
expanded when actually used, if ever.

It's at the time they are used that they must resolve to something without 
errors, not during definition.

-----Original Message----- 
From: rempas via Tinycc-devel
Sent: Monday, December 13, 2021 12:01 PM
To: Tinycc Devel
Cc: rempas@tutanota.com
Subject: [Tinycc-devel] How many pases tcc doesn? Could we make a faster 
compiler than tcc for another language?

It is said that TCC is a single pass compiler but is this true? I mean 
unless the
definition of "pass" is not what I think, isn't TCC also preprocessing the 
file so
it should do more right? Let's conciser the following code:

```

#include <stdio.h>

#define final add(17, 173)

#define add(a, b) a + b

int main() {
 printf("%d", final);
}

```

Here the macro "add" should be expanded inside the macro "final" but how 
does
TCC knows about "add" if it is defined after "final". How many passe does it 
make?
What's the approach TCC takes in this case? The "#include" preprocessor also 
makes
a lot of unnecessary re-writes to a new bigger file while we could just use 
modules
to just read the symbols and their decloration and not the actual definition

What happens now if we try to create a new language that doesn't have 
preprocessors
and is a true single pass? From what I heard, other than preprocessing, the 
syntax of the
C programming language doesn't help either. A lot of things are not clear 
because the syntax
for a lot of things are the same up to a point. Consider the following 
example:

```

// Function decoration
int add(int x, int y);

// Function definition
int add(int x, int y) { }

```

What do you see? Yes the signature is the same up to the closing 
parentheses. So we
don't know what's going on up to this point. Now consider an example in our 
new language:

```

// Function decoration
dec fn add(int, int) => int;

// Function definition
fn add(int x, int y) => int { }

```

In this case we know now what's going one from the first word so the parses 
doesn't have
to check for any unnecessary cases. Watch how we could also just include 
only the type of
each parameter in the declaration as we simple don't care because it's only 
the signature and
not the actual body. Function pointers are also a mess. The same for casting 
without specifying
pretty much anything other than parentheses. This things also look bad in 
the eye of the
programmer.

So for the main point of the article? For anyone that is experienced with 
TCC and with compiler
and parser design in general, could we make anything at least 15-20% faster 
than TCC that will
also have syntax that looks better and more clear?

P.S. If you are intersted about what I said about the C syntax, you can 
check the following link
where I made the question and I got a great answer which is the answer I 
gave you here but
with more detail and explanation. Link:
https://cboard.cprogramming.com/c-programming/180715-parsing-cs-syntax-slow.html#post1303727

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel