Re: [Tinycc-devel] Extend tcc to use viable.

[Christian Jullien]

Hello Yair,

I only speak for myself but I doubt we will accept an extension to support a 
translator for a DLS that nobody knows.
As you write a translator to C, I'm sure that you can translate to something 
that will implement your behavior (macro, lib, ...). Remember that all C++ 
version up to CFront 3.0 where all C++ => C translators.
I don't think your DLS could be half as much complex as C++ 3.0 was.
A translator has not to be human readable. For example, my OpenLisp compiler, 
which can viewed as OpenLisp to C translator, resembles more to an assembler 
than to a C program. It compiles the complex ISLISP OOP language to a series of 
very basic C instructions and internal lib calls.

Writing a translator/compiler takes time, it took me around 3 months until I 
can translate 80% of OpenLisp and another 3 months to reach 95%. The next 5% 
took me 6 months (not full time). So around one year to be close to 100%. Ten 
years later I still have few bugs with obscure and very uncommon uses. 

M2c

Christian

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Yair Lenga
Sent: Thursday, February 24, 2022 19:39
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Extend tcc to use viable.

Hi,

I am working on a project to convert a proprietary DSL language into standard 
one. The proprietary language is executed by interpreter engine from intermedia 
representation. The challenge is maintaining the language and the runtime.

I am exploring an option to use compile-on-the-fly approach by translating the 
DSL to c, compile/execute in memory. Language is Fortran/c style, and is “safe” 
(no pointers, atomic strings, and bound-checked arrays) - most statements can 
be converted to c.

One challenge is methods. Language allow simple OO calls obj->method. The 
challenge is how to tell obj->prop (value), vs obj->method (function call). The 
translator can do it, if it will build parse tree, symbol tables. This is much 
more work than a statement by statement translator.

I was hoping it will be possible to make a small change to tcc, introduce a new 
operator (e.g. obj@func), which will be equivalent to obj->method() (function 
call) or obj->prop (member value), based on the type of the member (function 
pointers). Can anyone comment on readability of making such a change to tcc ?

Thanks, yair

Sent from my iPad
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


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

[Tinycc-devel] Extend tcc to use viable.

[Yair Lenga]

Hi,

I am working on a project to convert a proprietary DSL language into standard 
one. The proprietary language is executed by interpreter engine from intermedia 
representation. The challenge is maintaining the language and the runtime.

I am exploring an option to use compile-on-the-fly approach by translating the 
DSL to c, compile/execute in memory. Language is Fortran/c style, and is “safe” 
(no pointers, atomic strings, and bound-checked arrays) - most statements can 
be converted to c.

One challenge is methods. Language allow simple OO calls obj->method. The 
challenge is how to tell obj->prop (value), vs obj->method (function call). The 
translator can do it, if it will build parse tree, symbol tables. This is much 
more work than a statement by statement translator.

I was hoping it will be possible to make a small change to tcc, introduce a new 
operator (e.g. obj@func), which will be equivalent to obj->method() (function 
call) or obj->prop (member value), based on the type of the member (function 
pointers). Can anyone comment on readability of making such a change to tcc ?

Thanks, yair

Sent from my iPad
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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?

[Ivo van Poorten]

On Thu, 24 Feb 2022 11:16:54 -0500 Christopher Conforti
 wrote:
> I hope I got this all straight, and I hope it helps!

Yes, you basically nailed it. If you have a parser for language, you
can either execute it directly in the language your parser
is written in (interpreter), or output intermediate code or assembly or
object code directly (like tcc does).

Writing a compiler starts with writing a parser for your language. What
you do after that (interpret or generate code) is of second concern.
Hope the OP understands that.

Regards,
Ivo

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

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?

[Christopher Conforti]

On Sat, 29 Jan 2022 10:08:11 +0100 (CET)
rempas via Tinycc-devel  wrote:
>
> 29 Ιαν 2022, 03:20 Από s...@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? Hm
> >> 
> > 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 
christop...@conforti.xyz 

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