On May 17, 12:04 am, Antony Vennard <[email protected]> wrote:
> Hi All,
>
> Regarding BSDNT (BSD Licensed MPIR) I think Bill mentioned targetting
> pcc earlier on in conversation (cl/icc/gcc have also been mentioned as I
> remember it). One thing that was suggested was porting pcc to Win64,
> something I've been having a look at (which is what happens when your
> primary contract is web design... you go LOOKING at compiler source).
>
> Anyway - the Win32 build process is via pcc/os/win32/build.bat which
> targets i386 win32. In terms of building the compiler, most of it
> compiles correctly under MSVC 64 bit (Win7SDK x64 tools) with the
> exception of two parts:
> * ../../../pcc-libs/libpcc/_ftol.asm, a MASM 32-bit "ftol" function
> (float to long I think, from the instructions). This doesn't assemble
> under ml64 which seems to have trouble understanding the ml syntax.
> * ../../../pcc-libs/libpcc/_alloca.asm, an implementation of alloca for
> pcc which allows memory allocation on the stack.
>
> These two pieces seem to hold up the build for the entire project - not
> unsurprisingly, really.
>
> Successfully converting these files to win64 would build us a 64bit PE
> that compiles 32-bit obj. I believe pcc does not link but relies instead
> on external linkers to turn translation units into PE/DLL/LIB as
> necessary. Which means, the missing piece is creating 64-bit objects
> compatible with the win64 ABI. I've not got this far yet as this was a
> two-hour nosey last night.
Hi Antony,
>From what you say, it should not be too hard to get a 64-bit version
of pcc that builds 32-bit Windows applications.
My guess is that we should be able to find or produce the two broken
assembler files.
Unfortunately, however, there will be a lot of work involved in
buildinng for x64 since the ABI conventions are very different.
The compiler will need to take account of different register use in
calls, different scratch register lists, different stack use, function
generation in two different function classes (frame and leaf
functions), frame function prologues and epilogues (with the
generation of function annotation code) and stack unwiding support.
And, of course, entirely new code generation and optimisation to take
account of x64 instruction sets for an expanding range of x64
architectures.
In my view this is a BIG job. I don't want to put you off as it
would be a great contribution. But I don't want you to underestimate
the scale of the task.
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.
