Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx01.iad01.newshosting.com!newshosting.com!216.196.98.142.MISMATCH!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!nerds-end From: BGB Newsgroups: comp.compilers Subject: Re: GCC is 25 years old today Date: Fri, 30 Mar 2012 13:33:12 -0700 Organization: albasani.net Lines: 166 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-03-072@comp.compilers> References: <12-03-051@comp.compilers> <12-03-053@comp.compilers> <12-03-062@comp.compilers> <12-03-068@comp.compilers> <12-03-069@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1333180579 50782 64.57.183.58 (31 Mar 2012 07:56:19 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sat, 31 Mar 2012 07:56:19 +0000 (UTC) Keywords: GCC, code, Windows, comment Posted-Date: 31 Mar 2012 03:56:19 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com X-Received-Bytes: 8947 Xref: csiph.com comp.compilers:539 On 3/30/2012 1:58 AM, Hans-Peter Diettrich wrote: > BGB schrieb: > >> more recently, I have ended up mostly using MSVC, mostly because: >> it was also freely available (via the Platform SDK); >> it supported some features which at the time GCC didn't support (namely, >> Win64). > > IMO GCC and Windows is a special case, because the GNU developers > never really wanted to support this (non-free non-POSIX) platform. > Cygwin and MinGW do not fully support the WinAPI, and lack further > development support. Most GNU projects, including the development > tools and libraries, do not build on Windows, they mostly fail already > in ./configure. In the context of this group it should be mentioned > that a bunch of *languages* are involved in building GCC/GNU projects, > even if these languages are mostly interpreted, not compiled. See > shell scripts, make and auto... extensions, M4 and whatever else is > required or suggested by the FSF. partly, yes. it is kind of a horrible pain trying to get GCC to rebuild from source on Windows. but, it does work, and since then, GCC has added Win64 support, albeit whether or not it has become mature or migrated back into the "standard" compiler distributions is much less certain (apparently, it now comes by default with Cygwin). it is kind of a hassle to support various build configurations though. my current build configuration is mostly to use the "Windows SDK CMD Shell" thingy, but mostly reusing some of the build tools from either Cygwin or MinGW (mostly things like "make" and similar). > IMO nowadays the bare compiler is the least important part, WRT the > choice of a *development system*. Languages are another issue: you'll > hardly find two C++ compilers which are ABI compatible, not to mention > compatibility with other OO languages. yes, but luckily the C ABIs are a bit more stable. the usual answer is to use a C-level API for most potentially cross-compiler / cross-language interfacing (this is presently a limitation for my script language as well: it can link directly with C, but not with C++, so interfacing between my script language and C++ requires either a C-level interface, or the use of explicit boilerplate for marshaling method calls and similar). there does seem to be a little linker magic though, as I have observed before that code compiled with MSVC seems to crash if linked with a linker other than the MS linker (either my own linker, or the GNU linker), but haven't really investigated too much. seems to work ok the other way though (GCC output works in both my linker and MS's linker last I tested). note that, IMO, it would likely be easier to leave my VM using its own ABIs internally, and then attempt to generate "glue magic" to interface with C++, than it would be to try to make BGBScript able to directly use the various C++ ABIs. the "glue magic" would likely be an ugly hack to allow the VM to use and extend a subset of C++ classes (likely limited to "Single Inheritance" with a secondary option to allow "interfaces" implemented via abstract base classes or similar), generally likely involving generating "fake" vtables, partial wrapping, and trampoline thunks. however, there is enough nastiness in all of this where I have not yet bothered ("glue magic" is already used for most C interfacing, and is nasty enough as-is). > Java went an radically different way WRT portable code, eliminating OS > dependencies in the VM instead of fragile adaptation in source code > and libraries. This approach makes it much easier to develop > applications for multiple platforms, including multiple POSIX flavors. > I may be wrong here, but IMO the availability of Linux applications > depends heavily on the goodwill of the platform maintainers, which > have to make every single project compile, build and run on their > specific platform. Even if this is not a compiler issue, it suggests > to properly consider the role of an compiler in the entire development > process. Java, however, tends to be a "poor fit" on most platforms though. IMO, a compromise strategy could be better, where the language/compiler/VM/... allows some level of specialization on a per-platform basis (such as JIT-stage ifdef's), but is "mostly self contained" regarding things like compiling and executing code. sadly, there is still an issue with the "optimal binary deployment format", for example: raw native ELF or PE/COFF images (fairly nice on particular targets, nearly useless on others); VM images embedded in ELF or PE/COFF: sort of a compromise, can be very easy to launch on certain targets, but with little advantage on others (say, on Linux one has the issue of whether a given EXE needs to be launched with Mono or Wine, and binfmt_misc doesn't help as both have both the same signature and file extension); some sort of dedicated image with a custom file extension, which on current systems can be set up to work fairly nicely, but with the issue that it is then necessary to install/configure the VM (set up file associations and so on). in my case, my language/VM has several ways of operating: loading code/programs directly from source (currently the dominant strategy for script code); loading bytecode from archive-like images (conceptually similar to JARs, just using different file formats, not currently used much as this assumes deploying standalone code); producing VM images embedded in PE/COFF containers (similar to the .NET CLR strategy, not currently done, but has the possible merit of allowing direct C/BGBScript linking without generating/compiling intermediate C code, but the relevant mechanisms are currently Windows-only); embedding modules directly into native-code libraries (image contents are translated to globs of C strings, along with any generated glue-code, and then compiled/linked into a native library), which is currently the strategy used for most of the core library code (this was implemented first, and was/is planned to be replaced by the prior strategy, eventually). currently, there are 2 possible image archive formats: PKZIP (used by JAR, APK, ...), which in my case can be loaded into the VFS and used as part of the search-path; ExWAD, which is a "lighter-weight" alternative (loosely based on the Quake/Half-Life WAD2/WAD3 file-format), and also stealth to ZIP tools (considered a possible merit for some use-cases). in both embedding strategies, the existence of VM script code (as separate from native code) is largely hidden away (apart from both cases depending on VM DLLs and similar). this is in contrast to, say, a JAR, where the matter of "hey, this thing is a Java app" are painfully obvious (just as much as its inability to conveniently interface with native code). I have, in the past, experimentally compiled/linked between .NET and BGBScript, but not made much practical use of this (as-is, it is a bit messy, as it involves using C++/CLI to interface between the C# and C areas, which are in turn used to interface with BGBScript). despite some semantic and costmetic similarities between the languages and VM technologies, there is no good/obvious way to do transparent cross VM interfaces (short of ugly hacks like auto-generated C++/CLI code or similar). granted, the use of "ugly hacks" to more directly glue the VMs together is possible, if nasty (say, tricking .NET into thinking it is dealing with C++/CLI, and supporting a C++ interface in my language, and all the nastiness in between). either way, it wouldn't work with Mono. theoretically, a .NET port of the VM could be made, but I am not personally inclined to bother with this. [Porting to .NET would be a challenge, since you'd have to graft on the whole .NET type system. -John]