Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.misty.com!news.iecc.com!.POSTED!nerds-end
From: Hans-Peter Diettrich <DrDiettrich1@aol.com>
Newsgroups: comp.compilers
Subject: Re: Trouble implementing a standard library -- Calling C functions from within my language
Date: Thu, 20 Mar 2014 03:37:23 +0100
Organization: Compilers Central
Lines: 22
Sender: news@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <14-03-050@comp.compilers>
References: <14-03-049@comp.compilers>
NNTP-Posting-Host: news.iecc.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: miucha.iecc.com 1395286814 99703 2001:470:1f07:1126:0:676f:7373:6970 (20 Mar 2014 03:40:14 GMT)
X-Complaints-To: abuse@iecc.com
NNTP-Posting-Date: Thu, 20 Mar 2014 03:40:14 +0000 (UTC)
Keywords: design
Posted-Date: 19 Mar 2014 23:40:14 EDT
X-submission-address: compilers@iecc.com
X-moderator-address: compilers-request@iecc.com
X-FAQ-and-archives: http://compilers.iecc.com
Xref: csiph.com comp.compilers:1172

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