[Tinycc-devel] Re: patches for libtcc

[Rob Landley]

I had this window open to reply to, but I was uninvited from the project and 
have stopped working on it now.  If you want to talk to somebody about it, 
there's always the mailing list...

Rob

On Tuesday 11 September 2007 2:17:01 pm Gabriel Corneanu wrote:
> My comments inserted:
> > > Because compilation speed is listed as a main target, I thought we
> > > could keep global variables just as they were, because
> >
> > there is only
> >
> > > one state anyway (in standalone version).
> > > The overhead is just extra dereferences, but I don't think
> >
> > it would be
> >
> > > significant.
> >
> > It's a separate cleanup and doesn't need to block this one.
>
> I mean there would be a lot of (compile-time) references to the structure
> fields, instead of globals. I don't think it would make a big difference,
> but maybe one could measure.
>
> > > No other good reason than easily readable changes.
> >
> > I'd prefer to have the most correct changes than the most
> > minimal changes possible.
>
> I also want a cleaner code, but my first goal was to make it work.
>
> > A sub-structure shouldn't have noticeable runtime overhead.
> > (Hmmm, I wonder if tcc will combine the offsets or do the
> > math twice at runtime?)
>
> Normally I would expect the offsets to be combined.
> Maybe tcc doesn't, but I usually compile tcc with another compiler.
> Anyway, for me compilation speed is not that critical.
>
> > > > > -move state dependent variables in a structure
> >
> > (TCCCompState) and
> >
> > > > > make wrapping macros
> > > >
> > > > I prefer not to do macros at all, and just change the uses of the
> > > > variables. (Macros make it non-obvious what the code is
> >
> > doing, which
> >
> > > > is
> > > > bad.)
> > > >
> > > > And these changes can be made incrementally.
> > >
> > > I also don't want macros, but it was easier for me to apply changes
> > > which would not require modifications in any other source file.
> > > If it is generally accepted, of course it's better to refactor the
> > > source code.
> >
> > One thing to keep the noise down is that we don't have to
> > move _all_ the variables in one patch if we don't want to.
> > It naturally splits up by variable...
>
> I only moved and created macros for variables which were needed to make it
> work.
>
> > > > > -store this in TCCState as opaque
> > > >
> > > > Store what, a pointer to the new structure you added?
> > >
> > > Yes. Again, just to keep changes simple (in tcc.h)
> >
> > Moving the new variables into TCCState definitely makes sense then.
>
> And it would solve the include issue you mentioned below (the files can be
> included right after declaring the variables they need).
>
> > > > > -move included files lower
> > > >
> > > > I'm mixed about that.  On the one hand getting them out
> >
> > of the way
> >
> > > > is good. On the other, it implies they need access to
> >
> > more variables
> >
> > > > than they actually do...
> > > > I'd really like to make it so that those aren't #included but are
> > > > instead separately compiled and linked, which is how multiple .c
> > > > files normally work...
> > > >
> > > > > -use "LIBTCC_STORAGE" to switch off "static" keyword
> > > >
> > > > Why?  (Details, please?)
> > >
> > > When they are inside the struct, you can't use "static".
> >
> > When they are
> >
> > > not, static is good to avoid possible linker errors (same
> >
> > variables in
> >
> > > other files). Otherwise why was "static" used?
> >
> > General code hygiene, I think.
>
> Not only; there could possibly be linking warnings/errors if more files
> declare globals with same name.
>
> > Moving them into a struct all the time seems the logical thing to do.
>
> Yes, definitely.
>
> > > > > as long as each state is "prepared" standalone (parse /
> > > > > relocate...), these should work:
> > > > > - calling dynamic code from several states
> > > > > - multiple state create/delete
> > > >
> > > > I'm still not quite understanding this...
> > >
> > > Basically I wanted this:
> > >
> > > s1=tcc_new
> > > tcc_compile_string(s1,...)
> > > tcc_get_symbol(s1, f1, "foo")
> > >
> > > s2=tcc_new
> > > tcc_compile_string(s2,...)
> > > tcc_get_symbol(s2, f2, "foo")
> > >
> > > ... use f1(), f2()
> > >
> > > tcc_delete(s1)
> > > tcc_delete(s2)
> >
> > Hmmm...  So both compile instances have the same "foo" at the
> > same time?
>
> No, "foo" is just the name of the function (and it is not important); the
> actual function code is dynamically generated and can be very different.
> This is what I'm interested in.
> Sure, I could use only one state with different function names...
> But I'm in an OOP environment; each state is encapsulated in a very
> technical class, which has lots of instances. Combining all generated
> source code strings in one state would not be nice.
>
> > > Now it works, as long as they are "prepared" one at a time.
> > > The line
> > >     tcc_state = s1;
> > > in tcc_compile (and a few others) would work up to a point,
> >
> > but it's
> >
> > > still not very clean.
> > >
> > > To make it very clean (and maybe even thread safe), you
> >
> > need to remove
> >
> > > tcc_state completely and pass it to all functions.
> >
> > I don't personally care about thread safety, but if somebody
> > else does...
>
> Only create/compile/clean are not thread safe, and I can live with that.
> Once I have compiled code, it is thread safe. And I think about it as a
> "must".
> Of course, the compiled code must also be thread safe.
>
> Regards,
> Gabriel



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