Re: GCC is 25 years old today

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]

Return to the comp.compilers page.
Search the comp.compilers archives again.