tinycc-devel
[Top][All Lists]
Advanced

[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.



reply via email to

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