I don't know much about Windows, since I don't use it.
I use tcc to do two things:
1. compile my compiler
2. compile snippets of C which I then objdump to see the code generation.
I find tcc's output to be easier to read and simpler than that of
gcc or llvm, and less buggy than pcc (all of which I use as well). I
use what I learn to imrpove my code generation. I emit large mode
code, which is why I asked how to get tcc to emit that. Now I know it
won't, I'll quit trying to figure out how to do it.
I use large mode non-PIC code because it's the easiest to generate,
not because I need arrays bigger than 2GB or anything.
I thought putting the information about what style of code is
generated in the documentation somewhere would be helpful so other
people in the future don't ask about it, but I guess I'm the only one
who ever asked, so I can see why you feel there is no need to document
it.
Still, thanks for answering definitively so I can move on to other
things and quit trying to find a way to do it. The gcc compiler is
the only one that seems to reliably emit large mode code, and I had
hoped to copmare it to tcc's code, that's all. The llvm compiler
emits large mode code, but it's buggy, and I guess (but don't know)
that pcc only emits small mode code like tcc does. So I do have a
use case, but a strange one, and I guess the consensus is that
supporting multiple code models would be outside the scope of tcc
because it would make it more complex and less tiny.
If there was only one feature that could be added, the best would be
to allow tcc to emit gas assembly (of it's existing small mode code).
I really do miss that feature, but objdump and readelf let me extract
the code sequences, so I still find tcc useful.
I also use tcc as a test to make sure my compiler code isn't using
anything too non-standard. I want to avoid gcc-isms, etc. It also
compiles much more quickly, so I can do more edit/compile/run
sequences per hour, which I like. Then once things seem stable, I do
the longer tests wtih pcc/gcc/clang to double-check. Again, I suspect
using tcc this way is not a standard use case either, but you did ask
how I use it, so I felt compelled to tell you. [smile]
So my wish list, as an unusual, non-standard tcc user, would be:
1. Make an official new release at least once a year so distros would
upgrade their tcc and I wouldn't have to custom compile for each and
every single machine where I use it. That last release was years and
years ago, and the first comment on every mailing list post about tcc
is often something like "The last release should not be used. Build
it from git." It would be nice if the truth was "The last release is
pretty good. If you want to test the next release, build it from
git." instead. Everybody would benefit from this.
2. Support -S to generate gas assembly. Only strange people like me
who read the generated code would benefit from this, so I doubt this
would be considered worth it.
On 11/9/20, Michael Matz <matz....@frakked.de> wrote:
> Hello,
>
> On Mon, 9 Nov 2020, Somchai Smythe wrote:
>
>> I guess it's documented somewhere, and I tried to find out that way,
>> but failed. I looked in the tcc git root directory README file, the
>> man page, the TODO, the wikipedia page
>> https://en.wikipedia.org/wiki/Tiny_C_Compiler,
>> https://bellard.org/tcc/, https://bellard.org/tcc/tcc-doc.html, and
>> tried using Google and Bing with no luck. I tried grepping the source
>> and only found one file, ./elf.h, that was non-windows-centric and
>
> Does Windows even support the large code model?
>
>> mentioned models, but they didn't seem to indicate what model is used.
>> It did menion huge model though:
>>
>> #define SHN_PARISC_HUGE_COMMON 0xff01 /* Common blocks in huge model.
>> */
>>
>> which is why I asked the original question.
>
> That's PA-RISC, not x86-64. But may I ask why you went to such great
> lengths to find anything about the large code model on x86-64? What's
> your usecase?
>
> I'm not sure if the README or other documentation should specify
> unsupported things as that list is unlimited. The normal course of action
> would be to document supported features, implying that everything not
> mentioned can't be expected to be supported. (Of course, TCCs current
> docu hasn't reached that ideal yet either).
>
>
> Ciao,
> Michael.
>
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
