Re: [Tinycc-devel] c extensions
Sorry for not responding to this sooner. I have two suggestions. First, if you have not already done so, I recommend reading this book about Object Oriented C http://www.cs.rit.edu/~ats/books/ooc.pdf. thanks for the recommendation, but I already went through this path. I found even more sophisticated approaches that inspired me. You did probably not follow my earlier posts about the topic, but decided to hack the tcc as just got stuck by the limits of the pre-processor. It will likely give you all of the technical background that you need to implement what you want. Second, tcc is a one-shot parser. If you want any preprocessing, you'll need to implement that yourself. well... that is kind of obvious ;) ... But I do not want preprocessor. Try to de-focus from that and focus a bit on the freedom of adding C style construct that would be much much more powerfull than any kind of yet another preprocessor hack. So, really thanks, but I was really sitting on the problematics and please do not take it as I would be stubborn, but the most original solution to my problem would be to be able to add these extensions to tcc. One of the reasons I put my project on hold is that lot of things are happening on the repo lot of code changes. Also I did not get clear feedback if I should care to stay in sync or fork, with other words such changes would be ever accepted upstream. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] c extensions
On 05/30/2014 09:02, David Mertens wrote: ... I recommend reading this book about Object Oriented C http://www.cs.rit.edu/%7Eats/books/ooc.pdf. It will likely give you all of the technical background that you need to implement what you want. The sources of cfront, (the original C++ to C preprocessor,) are available here: http://www.softwarepreservation.org/projects/c_plus_plus/ thanks, I am aware about it... But for me it is important the speed of tcc and also the hackability. Starting to hack an already implemented complex code would take much more effort than to add the few magic lines to tcc that would just generate C code from the original code or directly compiled code. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] c extensions
Hey Mobi, Sorry for not responding to this sooner. I have two suggestions. First, if you have not already done so, I recommend reading this book about Object Oriented C http://www.cs.rit.edu/~ats/books/ooc.pdf. It will likely give you all of the technical background that you need to implement what you want. Second, tcc is a one-shot parser. If you want any preprocessing, you'll need to implement that yourself. Of course, you can write a simple preprocessor in Perl which would take some almost-C syntax and produce an ANSI-C file for you, which you then feed into tcc or gcc or whatever. Alternatively, you can write your own executable that links to libtcc. You would do some string preprocessing, then send the final output to tcc_compile_string. If you are comfortable with Perl, you can write an experimental preprocessor and feed the resulting strings straight into tcc using the C::TinyCompiler module. I hoe that helps! David On Fri, Apr 18, 2014 at 9:15 AM, mobi phil m...@mobiphil.com wrote: P.S. what would be yet even more complicated but interesting is to add a kind of 2 phase compile, where the head of the tcc parser would be able to parse the translated (or pre-parsed code) code the same way as it does with the macro expansion. On Fri, Apr 18, 2014 at 3:13 PM, mobi phil m...@mobiphil.com wrote: Domingo, thanks for your quick answer. Please note that one of the reason I want to stay tcc is: - the speed and relative simplicity, this is probably the reason keeps all of you close to tcc - I want to stay C syntax. Do not want to invent another language. Want just to embed constructs to the existing language. so for these reasons things like lex/yacc, vala etc. are out of question. Had a look at the other links as well, but they are far from what I want. I would love to see C evolving without the dictated by committee syndrome (or whatsoever is the pejorative) and tcc would be probably a nice opportunity to experiment. mobi phil -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian Kernighan ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] c extensions
On 05/30/2014 09:02, David Mertens wrote: ... I recommend reading this book about Object Oriented C http://www.cs.rit.edu/%7Eats/books/ooc.pdf. It will likely give you all of the technical background that you need to implement what you want. The sources of cfront, (the original C++ to C preprocessor,) are available here: http://www.softwarepreservation.org/projects/c_plus_plus/ -- Roberto Waltman ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] c extensions
Hi,
I know that this topic was here few times, last time I came with some
questions.
The goal of this email is both to purpose some simple tcc meta extension
and to ask
some further help to implement what I need.
My intention is to extend C with some features for object (oriented)
programming.
In my previous email about the topic I mentioned that I wanted to implement
those
extensions with macros. Though I invested a lot of time, I realized that it
was rather
a stoic exercise and with the macros will be impossible to implement more
powerful
constructs like type checking.
After lot of brainstorming, I have a better understanding of what
extensions I would like
to have and how I want to implement them.
I will basically need 4 constructs:
1. a struct like construct, black. This is the blackbox of the object.
This will be mainly
defined in the source file and holds private objects/members. So far did
not find
a better name. One candidate would be implementation, but it is also not
really
the implementation etc.
example:
black MyType
{
type1 member1;
type2 member2;
type3 member3;
};
2. a struct like construct, white. Again, did not find a better name,
interface could have
been a candidate, but the real interface to the object will be the virtual
methods declared
inside the white block + the static methods that are defined outside of
the block.
white MyType: Object /* inheritance, though there will be no public/private
keywoards for the moment */
{
type1 aVirtualMethod();
type1 member1; /* this is the declaration of on accessor that will be
bound to the one with
same name from the /*black*/
}
3. a method declaration and definiton. This will be similar to the C++
method definition.
/* in the header file */
type1 MyType:.aNonVirtualMethod();
/* later in the implementation file */
type1 MyType:.aNonVirtualMethod();
note here the usage of the :. instead of :: as the semantic is a bit
different than in C++
4. method call
type1 object;
object..aVirtualMethod();
the token here is .. instead of . or -
This is again has different semantics. But would not bother with details
for the moment.
Further new constructs are in my mind for fibers, continuations (yes they
will be different) and and.
Decided to call this babel C, so files will probably have extension bh/bc
(header/implementation)
The bc file will be translated into pure C by the modified tcc. A construct
like 1. will be translated into
a C struct with some additional part etc + some glue code. (Will not go
into details, but will publish soon the details).
Construct 2 will be also translated into a struc + some glue code, the same
with 3. and 4.
I studied the tcc parser and compiler bit more in depth. Found more or less
where I should patch. I kept things easy,
(you remember wanted to use some special syntax with @ etc. etc.), so that
my stuff fits easyl
into the parsers logic.
What I need now and this is the minimum that would be probably nice to see
it going upstream.
My first naiv approach wast to save a pointer in the input buffer and:
- anything that is normal C syntax, after successful parsing of a
declaration or part of a declaration,
send the input to the output
- anything that is syntax extension, fill in a kind of template and send
the result to the output.
This task became though a bit complex for me due to the pre-processing. Got
a bit lost with token managemnt,
but probably after further hours could find the solution. Though some hints
would be welcome.
I got the suggestion to separate the code from original tcc, keep the
parser and implement my code generation.
Not sure that this would make my life easier. Do not think this is a good
idea as the assembly code generation
bits would not disturb me (the part that would be redundant for me).
My own first question seems to be confusing as it is not easy to ask it
:)... I am rather expecting some hints..
The second question if you could suggest some basic changes in the parser
and supporting code that
would make life easier to implement such extensions for code generation.
thanks a lot,
mobi phil
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] c extensions
I like your idea in principle, have you thought to use a tool like led/peg
parser http://piumarta.com/software/peg/ using a C grammar like
http://www.romanredz.se/freesoft.htm#C, you'll have more freedom to express
your ideas.
Also maybe you already know this:
- http://milgra.com/classc/
- pcc http://pcc.ludd.ltu.se/ has the beginings of a c++ made on top of c
uses bison/yacc.
- vala https://wiki.gnome.org/Projects/Vala
- Class-C source-to-source compiler http://www.milgra.com/classc
- https://github.com/ryanashcraft/Classified-C
Cheers !
On Fri, Apr 18, 2014 at 12:17 PM, mobi phil m...@mobiphil.com wrote:
Hi,
I know that this topic was here few times, last time I came with some
questions.
The goal of this email is both to purpose some simple tcc meta extension
and to ask
some further help to implement what I need.
My intention is to extend C with some features for object (oriented)
programming.
In my previous email about the topic I mentioned that I wanted to
implement those
extensions with macros. Though I invested a lot of time, I realized that
it was rather
a stoic exercise and with the macros will be impossible to implement more
powerful
constructs like type checking.
After lot of brainstorming, I have a better understanding of what
extensions I would like
to have and how I want to implement them.
I will basically need 4 constructs:
1. a struct like construct, black. This is the blackbox of the object.
This will be mainly
defined in the source file and holds private objects/members. So far did
not find
a better name. One candidate would be implementation, but it is also not
really
the implementation etc.
example:
black MyType
{
type1 member1;
type2 member2;
type3 member3;
};
2. a struct like construct, white. Again, did not find a better name,
interface could have
been a candidate, but the real interface to the object will be the virtual
methods declared
inside the white block + the static methods that are defined outside of
the block.
white MyType: Object /* inheritance, though there will be no
public/private keywoards for the moment */
{
type1 aVirtualMethod();
type1 member1; /* this is the declaration of on accessor that will be
bound to the one with
same name from the /*black*/
}
3. a method declaration and definiton. This will be similar to the C++
method definition.
/* in the header file */
type1 MyType:.aNonVirtualMethod();
/* later in the implementation file */
type1 MyType:.aNonVirtualMethod();
note here the usage of the :. instead of :: as the semantic is a bit
different than in C++
4. method call
type1 object;
object..aVirtualMethod();
the token here is .. instead of . or -
This is again has different semantics. But would not bother with details
for the moment.
Further new constructs are in my mind for fibers, continuations (yes they
will be different) and and.
Decided to call this babel C, so files will probably have extension
bh/bc (header/implementation)
The bc file will be translated into pure C by the modified tcc. A
construct like 1. will be translated into
a C struct with some additional part etc + some glue code. (Will not go
into details, but will publish soon the details).
Construct 2 will be also translated into a struc + some glue code, the
same with 3. and 4.
I studied the tcc parser and compiler bit more in depth. Found more or
less where I should patch. I kept things easy,
(you remember wanted to use some special syntax with @ etc. etc.), so
that my stuff fits easyl
into the parsers logic.
What I need now and this is the minimum that would be probably nice to see
it going upstream.
My first naiv approach wast to save a pointer in the input buffer and:
- anything that is normal C syntax, after successful parsing of a
declaration or part of a declaration,
send the input to the output
- anything that is syntax extension, fill in a kind of template and send
the result to the output.
This task became though a bit complex for me due to the pre-processing.
Got a bit lost with token managemnt,
but probably after further hours could find the solution. Though some
hints would be welcome.
I got the suggestion to separate the code from original tcc, keep the
parser and implement my code generation.
Not sure that this would make my life easier. Do not think this is a good
idea as the assembly code generation
bits would not disturb me (the part that would be redundant for me).
My own first question seems to be confusing as it is not easy to ask it
:)... I am rather expecting some hints..
The second question if you could suggest some basic changes in the parser
and supporting code that
would make life easier to implement such extensions for code generation.
thanks a lot,
mobi phil
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] c extensions
Domingo, thanks for your quick answer. Please note that one of the reason I want to stay tcc is: - the speed and relative simplicity, this is probably the reason keeps all of you close to tcc - I want to stay C syntax. Do not want to invent another language. Want just to embed constructs to the existing language. so for these reasons things like lex/yacc, vala etc. are out of question. Had a look at the other links as well, but they are far from what I want. I would love to see C evolving without the dictated by committee syndrome (or whatsoever is the pejorative) and tcc would be probably a nice opportunity to experiment. mobi phil ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] c extensions
P.S. what would be yet even more complicated but interesting is to add a kind of 2 phase compile, where the head of the tcc parser would be able to parse the translated (or pre-parsed code) code the same way as it does with the macro expansion. On Fri, Apr 18, 2014 at 3:13 PM, mobi phil m...@mobiphil.com wrote: Domingo, thanks for your quick answer. Please note that one of the reason I want to stay tcc is: - the speed and relative simplicity, this is probably the reason keeps all of you close to tcc - I want to stay C syntax. Do not want to invent another language. Want just to embed constructs to the existing language. so for these reasons things like lex/yacc, vala etc. are out of question. Had a look at the other links as well, but they are far from what I want. I would love to see C evolving without the dictated by committee syndrome (or whatsoever is the pejorative) and tcc would be probably a nice opportunity to experiment. mobi phil -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
