tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Christian Jullien
Subject: Re: [Tinycc-devel] Extend tcc to use viable.
Date: Fri, 25 Feb 2022 07:27:13 +0100

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.fr@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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]