Re: [Tinycc-devel] Extension to C language

[Jared Maddox]

> Date: Fri, 1 Jun 2012 09:02:01 +0100
> From: Rob <address@hidden>
> To: address@hidden
> Subject: Re: [Tinycc-devel] Extension to C language
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>

>> This is required in order to maintain compatibility with already
>> existing C code & compilers, which expect specific function names to
>> accept specific argument sets.
>
> The compatibility is maintained by calling it _Generic - a keyword that
> has been reserved since a previous standard.
>

No, I was talking about functions & their names, not _Generic. I
consider _Generic to only be a mechanism in this case, rather than a
subject in it's own right.

>> Generics could presumably make it easier to deal with the multiple
>> argument sets required for overloading, but the overloading itself
>> would inherently require either Decorated Names or Dynamic Dispatch,
>> and I'm not certain that Dynamic Dispatch should be considered a valid
>> way of implementing Operator Overloading in a low-level language like
>> C. It's an implementation thing.
>
> There is no need for decorated names, nor dynamic dispatch.
>
> void myfunc_int(  int   i){ printf("%d\n", i); }
> void myfunc_float(float f){ printf("%f\n", f); }
>
> #define myfunc(arg) _Generic(arg, int: myfunc_int, float:
> myfunc_float)(arg)
>
> It looks like a preprocessor feature because its main use is in a macro
> definition, but the _Generic expression itself is parsed by the
> compiler. The preprocessor replaces myfunc() with _Generic(...), which
> the compiler then replaces with the correct function call, without name
> decoration/dynamic dispatch.
>

Okay... except that I consider myfunc)_int and myfunc_float in this
case to be decorated names for myfunc. Decorated names are simply
names that have a little extra bit tacked on to differentiate
otherwise identical names from each other.

Looking back though, was this about Operator Overloading the entire
time? For some reason I thought it was a discussion of more generic
Function overloading. What I've said about overloading requiring
either decorated names or dynamic dispatch still holds for that,
though. And if Operator Overloading is implemented with functions,
then it applies to that by extension. You can't have overloaded
functions in C without adding something (either name decoration, or
dynamic dispatch, or something equivalent), because the C language
simply does not provide the facilities for Function Overloading on
it's own.

>> As separate extension thoughts:
>>
>> 1) is there a TCC Make? I haven't found any sign of one, but I might
>> be overlooking it. If there isn't one then I might try my hand at
>> implementing one. I'm thinking a max of 255 rules, max 255 variables
>> (including the ones local to targets), max post-expansion command
>> length of 255 characters (seeing a pattern?), and some GNUish 'if'
>> statements. Thoughts? Would the -run switch for this need to switch to
>> internal-only commands (in case of e.g. tcc-boot)?
>
> Seems like an interesting idea, but would tcc make then tag on a call to
> tcc -run?

Huh? What are you trying to say? Are you referring to a problem with
the number of arguments you can pass in a sha-bang? Because that could
plausibly be solved with a -runmake flag.

> I don't see how this can offer advantages over the standard
> make.
>

I'm thinking specifically of the old compile-linux-at-boot-time
gimmick. I think it (and anything similar) would probably be easier to
support with a build-system actually built into TCC. Also, given that
make is so ubiquitous within compiler systems that even Microsoft
provides a version (seriously, they do, go look it up), it really does
seem to me that it makes sense for TCC as well. Make is essentially a
standard compile tool.

>> 2) How about preprocessor extensions? I've thought about two types of
>> loops (for code generation purposes, e.g. for switches):
>
> Some of this seems like coming up with extensions for the sake of it.
> They're decent ideas, I just think they should stay in the tcc-extended
> branch or something.
>

Actually, I thought of the two preprocessor loops maybe a year (or
more) ago, I just haven't bothered to try implementing them. The
design has some specific reasons behind it: the reason why there
weren't loops in the preprocessor in the first place was to avoid the
risk of infinite loops, which these two are designed to also avoid.

Is there currently a tcc-extended branch? I didn't notice one on the
git repo yesterday.