> Speeding up compilation is always nice (and if anyone wants to dive into the > unit loading logic, solve its existing problems and make it multi-threading > safe, I'd be delighted -- I already spent several weeks on trying, and > largely failing, to merely solve particular bugs in it), but I fail to see > how that is in any way related to the current thread.
I had the same reaction when I went to install FPC on WinXP64. I didn't post b/c I already knew that there was no native FPC x64 for Windows. This thread was started with the notion that something exists that does not :-) Which is why I'm saying in order to make it "feasible" to exist we are going to need to overcome the barriers that make native x64 distro on Windows feasible. The argument against Win64 native is due to the fact that 64bit pointers are twice the size of 32bit pointers... With that statement... Florain's assertion was native 64 would be larger and slower to compile units. Someone also suggested that a native Win64 would be a larger executable - which to me is not even a factor. IMO: Native debugging under x64 would be the number 1 reason or justification for doing the work. The second would be for distribution. The third and most important would be for consistency. Is it normal to have to cross compile to a platform you want to develop under daily? Windows version of gdb offers better stability than that of Xwindows (gdm keeps needing to be started for threaded apps). Anyways.. All of these arguments are worth the discussion as they do in fact relate to why there is no Win64 folder :-) _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
