Re: Trouble implementing a standard library -- Calling C functions from within my language

Hans-Peter Diettrich <DrDiettrich1@aol.com>
Thu, 20 Mar 2014 03:37:23 +0100

          From comp.compilers

Related articles
Trouble implementing a standard library -- Calling C functions from wi noitalmost@cox.net (noitalmost) (2014-03-19)
Re: Trouble implementing a standard library -- Calling C functions fro DrDiettrich1@aol.com (Hans-Peter Diettrich) (2014-03-20)
Re: Trouble implementing a standard library -- Calling C functions fro alexfrunews@gmail.com (2014-03-19)
Re: Trouble implementing a standard library -- Calling C functions fro noitalmost@cox.net (noitalmost) (2014-03-21)
| List of all articles for this month |

From: Hans-Peter Diettrich <DrDiettrich1@aol.com>
Newsgroups: comp.compilers
Date: Thu, 20 Mar 2014 03:37:23 +0100
Organization: Compilers Central
References: 14-03-049
Keywords: design
Posted-Date: 19 Mar 2014 23:40:14 EDT

noitalmost schrieb:


> And then have
> class CCall : public Expr
> {
> CCall(string name, vector<Expr*> params);
> string genC();
> ...
> }
>
> where, Expr is a AstNode. But CCall::genC() would be a really
> complicated list of special cases.


Right now I see a problem with Expr (lval), when the C function
expects an pointer (rval). This should be handled at least for
variables, i.e. Expr should include an hint on whether it *is* an
lval. When you produce C code, your data types already should match
the C definitions, else another transformation may be required for
passing parameters back and forth. All that should be built into Expr,
or a DataType member of Expr.


DoDi


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.