[Tinycc-devel] TCCState, tcc_state, and ch/file/tok

[Peter \"Firefly\" Lund]

What is the point with having several TCCStates around when there is only
one tcc_state, ch, file, and tok?

If we want to be able to have several, won't we need something like:

void tcc_set_state(TCCState *newstate)
{
  assert(newstate);

  tcc_state = newstate;
  file = tcc_state->current_file;
  ch   = file->buf_ptr[0];
  tok  = ???
}

TCCState has a current_file field in my tree (and ch/file are renamed to
tok_ch/tok_file but those names are not ideal).


tcc_close() should set tcc_state and file to NULL and ch and tok to some
kind of sentinel value.

I haven't made up my mind whether tcc_new() should imply tcc_set_state()
or not.



In fact it is a whole lot worse, since we have other globals:

  total_bytes, total_lines

  do_debug, do_bounds_check, do_bench, gnu_ext, tcc_ext, num_callers

  text_section, data_section, bss_section
  cur_text_section
  bounds_section
  lbounds_section

  symtab_section, strtab_section
  stab_section, stabstr_section

  rsym, anon_sym, ind, loc

do_debug and do_bounds_check probably belong inside TCCState where they
can keep nostdinc and static_link company.  I think gnu_ext, tcc_ext
should go there, too.

num_callers is used from inside a routine that tries to unwind the stack
in case of a run-time error.  I suppose it has to stay global.

total_bytes and total_lines should stay global and keep a global running
count on the number of bytes/lines processed.

Then there are all the sections.  The "real" section pointers (as in "the
canonical pointers that actually /own/ the data") should be moved inside
TCCState, I think, with their global counterparts being "shadows" that get
updated by tcc_set_state().  If they should still exist at all, that is.

I don't know what rsym, anon_sym, and loc are.

ind is the index into the current text section where the next opcode byte
goes.  It is not a pointer because the section buffer can be realloc'ed to
enlarge it at any time.  It should be faster to keep it as a global than
to read it through a dereferenced tcc_state all the time.  On the other
hand, the code generation is such a small cost in tcc that it hardly
matters.  If we keep it global and take the idea of several TCCStates so
seriously that we want to allow more than one text section then we would
want to copy ind /back/ into either the TCCState or into the text
section's data_offset field (which I think we only use for non-code
sections -- and I think we mess up if we temporarily generate code to
sections other than ".text").


Comments?

Are the multiple TCCStates just a bad idea?  What exactly are their
semantics supposed to be?

-Peter

"Of course, I'm not unbiased, but in my humble opinion, I've
 gotten close to something that I can be really proud of."
 -- Knuth on The Art of Computer Programming.