On Nov 29, 2:49 am, Bill Hart <[email protected]> wrote: > I've just been looking at the TCC compiler. > > http://bellard.org/tcc/ > > Advantages: > ========= > > - Cross platform - works on Windows and Linux > - Almost C99 compliant > - Supports GNU inline asm > - Compiles GNU .asm files > - Compiles and links unbelievably quickly, even on Windows > - Very small comprehensible codebase > - LGPL v2+ > - produces native Windows binaries > > Disadvantages: > =========== > > - Doesn't support SSE asm instructions (probably wouldn't be hard to > add support for these - the codebase is quite comprehensible) > - 32 bit x86 assembly only (the latest version supports "x86_64 > targets", but I am not sure what this means) > - probably doesn't optimise as well as gcc (though I did some basic > loop timings and they were fine) > > Well I just had a play, and it assembled almost all the k8 .asm files > in MPIR and almost all of the mpn .c files. The exceptions were the > multifunction files, due to the fact that a couple of defines are > missing (easily fixed and my fault) and perfsqr.c (perfsqr.h is > missing - also not the fault of tcc). It takes about 6s total to > assemble and compile all that stuff! That's faster than a 16 core > parallel build on Selmer!!!!!!!!!!!!!!!! > > There also seems to be some issue with alloca.h which I needed to work > around, as I know nothing about alloca.h. > > I'm actually really keen to build MPIR with TCC because I can also use > TCC to build FLINT on Windows. I checked and the longlong.h I use for > FLINT compiles fine with tcc. The only issue I can find with using it > to compile FLINT is that for (unsigned long i = 0; i < count; i++) > doesn't compile. It expects unsigned long i; for (i = 0; i < count; > i++). However a very simple script could easily fix this for all files > in FLINT. I'm sure this could also be easily fixed in TCC itself as > they are moving towards full c99 support and quite a few gnu > extensions. > > There seem to be some issues with tcc development stalling, but it > isn't a dead project. The last release was May 20th. > > I'm kind of confused about one thing. It looks to me that it supports > linux calling conventions. This is great if true, but maybe the > calling conventions don't differ on x86 32?
This is easy on x86 since there are very few differences in the calling conventions. I think it should be possible to use Linux calling conventions on Windows x64 as well if a compiler makes use of special libraries that handle the the differences in calling conventions before interfacing with the Windows standard libraries and interfaces. But I might haave missed something that prevents this. Brian -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
