[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] _Generic or __builtin_choose_expr
From: |
Michael Matz |
Subject: |
Re: [Tinycc-devel] _Generic or __builtin_choose_expr |
Date: |
Fri, 30 Jun 2017 17:25:10 +0200 (CEST) |
User-agent: |
Alpine 2.20 (LSU 67 2015-01-07) |
Hi,
On Fri, 30 Jun 2017, uso ewin wrote:
> I've clean my commit and merge everything on my my mob which should be
> easily mergeable with official mob:
> https://github.com/cosmo-ray/tcc/commit/d2659993274e076894e039cc654fc9e1617ed056
Yeah, already nicer. More suggestions below:
> > I've very briefly looked at your implementation: Don't use your
> > current way of parsing the controlling expression/type, you should be
> > able to reuse expr_type/parse_expr_type/parse_type (or parts of it).
>
> Thanks for your advice, and done on mob branch on my github, expr_type
> work great.
>
> As buying the official C11 standard from ISO is a little expensive for
> my, I use this draft for the implementation:
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
n1570 is the most recent draft before finalization of the standard. But
I guess for _Generic it doesn't matter. Now for the suggestion:
Instead of saving the tokens for the matching expression and evaluating it
after completely parsed, use the nocode_wanted facility to enable or
disable code generation for the matching and non-matching expressions.
Ala:
while (1) {
parse type
if (type matches)
expr_eq();
else {
nocode_wanted++;
expr_eq();
vpop();
nocode_wanted--;
}
}
(Obviously with all the added checking you already have in there for
double defaults or twice-matching types).
That should further simplify the code and make it nicer.
Ciao,
Michael.