[Tinycc-devel] Re: Sinus & tcc

[Rob Landley]

On Sunday 09 September 2007 5:41:24 pm Jakob Eriksson wrote:
> May God & antibiotics remove your sinus infection. I said a prayer for you.

Thanks.  I'm leaning towards the antibiotics myself, since presumably they're 
what's changed recently.

The rest of this message should probably be on the mailing list, mind if I 
repost my reply there?

[Note: I got permission.]

> -------
>
> I try to decrease the number of #if-defs in C code. What do you think of
> the concept I try to explain with this little patch?

I'll give it a look...

> I try to draw conclusions from your denouncement of "make". (I agree with
> you 100%, BTW.)
>
> There are two main thoughts here:
>
> 1) I include directly what a define tells me.

Makes sense, but #include <blah.c> seems bad form.  What programs _should_ do 
is "tcc file1.c file2.c file3.c -o blah", so you have the option of building 
the files individually and linking them in a separate pass.

The reason it's being done now is so that "make test2" can go "tcc -run 
tcc.c".  The problem is that -run is currently defined to take exactly one C 
file argument and all the rest are arguments to that that C file, so although 
you can build an executable out of multiple C files with a single command 
line, you can't run the result immediately.

Changing the semantics of -run aren't an option because A) it's an established 
UI that's easy to use, B) shell scripts starting with "#!/usr/bin/tcc -run" 
are _going_ to put the filename and arguments at the end of the command line 
in that order, and that's the main use for this feature.  We can't add a "--" 
either: shell scripts won't, it would break existing usage, and actually 
_requiring_ "--" is just too ugly.  Testing if the next argument ends in ".c" 
is too brittle: lots of programs other than tcc can operate on C source as 
arguments.

I suppose we could add a new --multirun that's a positional parameter going 
after all the arguments to the compiler, so any arguments after that are to 
the program to be run.  Or we could have a "runtcc.c" file that #includes all 
the other source files and either make the C files ok with that (make sure 
all the #includes are guarded and there aren't any conflicting statics) or 
else make some kind of #reset directive to go between #includes that 
says "we're starting a new file, forget everything you know (see the cleanup 
at the end of tcc_compile()), which seems ugly.

Hmmm...

> If TCC_TARGET_GEN is defined to i386.c, that file is included.

Possibly just "#define TCC_TARGET i386" and use that?

What does the _GEN tell us that _TARGET doesn't?  And we can add .c and .h to 
i386 as necessary, and rename the .c and .h files if that helps.

> If it is defined to armv.c, that file is included.
>
>
> These files should all contain functions with the same names, but with
> different
> implementations depending on platform, sort of like a HAL.

I haven't played with hal, but lots of things do that sort of thing.

> Also, the C preprocessor gets to play a little part of the same role
> that "make"
> used to play. (Conditional compile depending on what is defined.)

I still like the idea of cleanly separated and separately compilable files, if 
nothing else to keep complexity contained.

> 2) Instead of calling different functions with different names,
> depending on some
> random define, the same function is always called. Only it has different
> implementations
> depending on how TCC was configured. (Target CPU etc.)

*shrug*  Works for me.  TCC already makes a separate executable for each 
target type, and if we wanted to have them share code there's libtcc.  
(Making one executable do multiple output formats is an implementation detail 
that would be easy enough to retrofit and not really that useful anyway.)

> If this sounds O.K. with you, I can clean up tcc more and send more
> patches.

I'm interested in seeing the patches, but won't guarantee applying them until 
I've seen them.  Can you start with some small ones? :)

> If not, I would still like to help with TCC in some way, because I would
> also like self hosting
> embedded systems. I also have this weird idea of using C much as you
> would any scripting language.

That is tcc's strongest point so far.

> You could write register C files as a MISC binary in the kernel and let
> tcc handle it.

You don't even have to do that, the kernel knows about scripts starting 
with "#!" and "#!/usr/bin/tcc -r" works just fine today.

Heh, now I'm pondering source code as shared library.  "/usr/lib/zlib.c".  
That would require some tweaks to the shared library loader...

> regards,
> Jakob

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

tcc.diff
Description: Text Data