I've got a very basic configure and makefile working for MPIR using tcc on 32 bit Windows which assembles all the k8 assembly files and all the generic C mpn files.
If you want to clone the project: git clone http://selmer.warwick.ac.uk/MPIR-tcc.git MPIR-tcc Instructions on how to build the project are in README. So far, unless it detects your CPU as a k8, it will fail. If you don't have a k8, duplicate the following section in configure for your CPU type: k8) mpn_dirs="mpn/x86 mpn/x86/k7 mpn/x86/k7/mmx" ;; adjusting the paths correctly. No dll is produced yet, only object files. But it takes 10s to run configure and another 10s to assemble and compile all the relevant .asm/.c files on 32 bit Windows! If you want to clean up, just type: make clean None of the other build targets work yet. I've not tried to build on Linux, but note it is only going to work on a 32 bit linux box, if at all. Bill. 2009/11/29 Bill Hart <[email protected]>: > 2009/11/29 Cactus <[email protected]>: >> >> >> 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. > > That explains a few things. I recall for example that the 32 bit > Windows assembly code works just fine on 32 bit Windows using MinGW. > > I wonder how 64 bit MinGW works, whether it uses linux or Windows > calling conventions. > > The documentation with TCC is not great, so I couldn't say what they > do for their x86_64 targets. > >> >> 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. >> > > Yes, I guess there'd need to be some kind of wrapper around each of > the Windows standard functions. Callback functions would be tricky to > handle. But I suppose it would be possible for the wrapper to > automatically wrap such functions before handing them to Windows. > Performance might suffer a bit, though most Windows standard library > functions are probably fairly hefty in the first place. > > Anyhow, time to make this MPIR-tcc git repo. I doubt it will be a > terribly credible alternative to an MSVC version of Windows, but it > will have a simple non-autotools build system, it will compile > extremely fast on Windows and there are the other advantages I > mentioned. It could be useful for some users. > > Bill. > -- 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.
