Re: [Tinycc-devel] Hello and a few questions about using libtcc

[Michael Matz]

Hello,

In addition to the answers already given by Kyryl:

On Sun, 20 Dec 2020, Joshua Scholar wrote:

> Now questions about generated code.  The jit I'm hoping to make is for a
> language that's embarrassingly parallel, so I need to know how the generated
> code works with threads and stacks and contexts.
>
> 1) The simplest thing, what's the calling convention of generated
> functions?  On 64 bit windows?  On 64 bit Linux? 

TCC follows the native calling convention, i.e. msvc on windows and ELF 
psABI on linux.

> 2)  Is the TCC runtime multithread safe?

Depends what you mean by runtime:
a) if you mean the code of libtcc itself, i.e. compiler/linker: you can 
use several TCCStates from separate threads, but must not use the same 
TCCState concurrently.
b) if you mean the code of libtcc1, i.e. support routines sometimes used 
by the generated code: then, yes, that's thread-safe.  (It's also very 
minimal, there's not much in term of support code necessary).

> a) And what are the details?  Can I run generated code in multiple threads
> at once?  Does it use locks for anything?

Yes, the generated code is as thread-safe as the input C code is.  No it 
doesn't use locks for anything (the runtime support for boundschecking 
uses locks, but that's for debugging purposes).

> Is it at least as thread safe as C usually is, ie, you can do anything that
> doesn't involve a shared buffer like an implicit error string. Would it be
> fine as long as I put a critical section around some non-thread safe part?
>
> 3) Does the run time library use thread local storage?  

No.

> 4) If I did something weird like have a call out from generated code to my
> code, and my code returned on the same stack but in the context of a
> different thread than it entered from, would that break anything?

No.  Or, perhaps better said, it would break in the same way when the 
generated code would also be your code and not generated by TCC, i.e. TCC 
doesn't introduce additional restrictions.  In particular the usual 
makecontext/swapcontext way of implementing lightweight threads via stack 
switching should work just fine, as should any more unusual way of 
switching threads but not stack (what is that even supposed to mean?), as 
long as the input code doesn't have any problem if it had been written 
literally without TCC involvement.

> 5) Some systems are broken by fibers, ie, if I switched between generated
> code, each using a different stack, but in the same thread, would that break
> anything?

See above, stack switching shouldn't be affected by TCC-generated code, if 
the input C source isn't.

> 6) Are there any pointers on how to use the built in assembler?

It's the GCC builtin assembler syntax, but only for i386/x86-64, and with 
some limits.  The limits aren't documented and subject to change if more 
things are needed.  As for usage documentation have a look at GCCs docu:

https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Using-Assembly-Language-with-C.html


Ciao,
Michael.