Re: [Tinycc-devel] Can a biggener (and idiot) like me read and understand TCC's backend so I can create my own frontend with it?

[rempas]

24 Φεβ 2022, 18:16 Από christopher@conforti.xyz:

> On Sat, 29 Jan 2022 10:08:11 +0100 (CET)
> rempas via Tinycc-devel <tinycc-devel@nongnu.org> wrote:
>
>>
>> 29 Ιαν 2022, 03:20 Από sean@conman.org:
>>
>> > It was thus said that the Great rempas via Tinycc-devel once stated:
>> >
>> >> Thanks! However, I don't understand how this will help me. I mean, I don't
>> >> even want to create an intepreter to begin with. So this has nothing to do
>> >> with what I want to make. Unless you are referring to the frontend so in
>> >> this case, It will probably be a good idea to read this book. Or maybe I
>> >> should make an intepreter in the end? Hmmmmm....
>> >> 
>> > It's interpreters all the way down (what do you think CPUs do with machine
>> > code?  They interpret it).  Also, if you have parsed code into a form you
>> > can interpret, you have enough information to generate machine code.
>> > 
>> I know that the CPU interprets the instructions but an interpreter will use
>> a programming language to interpret.
>>
>
> Mind that I'm still very new (and usually a lurker), but I think I can help.
>
> Machine instructions are just another programming language, and programming
> languages are fancier machine instructions. Compilers and interpreters both
> do the same thing--interpret higher-level languages into lower-level 
> languages.
> All the way from shell scripts (or batch files, for the Winders users) down to
> assembler, until at the bottom is machine code.
>
> The difference between a "compiler" and "interpreter" is that the 
> "interpreter"
> is usually running (like 'tcc -run') and passing its results directly to
> another interpreter (usually the CPU, but could be, for example, a JRE
> (spit-balling)) for execution NOW, while the "compiler" runs once (like 'tcc
> -o') typically puts its results in a file, to be read at an arbitrary time by
> another interpreter (again, usually the CPU but could be something like a JVM)
> for execution LATER.
>
> Further, an "interpreter" can pass its results to a "compiler" for
> immediate compilation, and a "compiler" can pass its results directly to an
> "interpreter" for immediate execution. Taking Python as an example: an
> "interpreter" could be written that translates Python into C, the output
> of which could be redirected into something like 'tcc -run' in real time; an
> "interpreter" could be written that translates C into Python, the results of
> which could be redirected into a Python interpreter in real time. "Compilers"
> could be written to "compile" C into a Python source file, and vice-versa, for
> later execution by an appropriate interpreter.
>
> This, by the way, is essentially how Java works: a Java source file is
> "compiled" into Java Virtual Machine code (kinda like CPU instructions), which
> is interpreted by the Java Runtime Environment, which passes the results to 
> your
> CPU. I've always found this aspect of the Java system very interesting.
>
> I hope I got this all straight, and I hope it helps!
>
> -- 
> Christopher Conforti
> Independent Cutco Sales Representative
> +1-717-281-6059 <tel:+1-717-281-6059>
> christopher@conforti.xyz <mailto:christopher@conforti.xyz>
>
Thank you, you got everything straight except for one thing. In your example on 
converting "C" to "Python" and vice versa. You cannot create an "interpreter" 
that will have an output because interpreters don't have an output. This is 
what we call a "compiler".

The front-end is the same bad interpreters execute the code rather than output 
a (or multiple) file.