GCC is 25 years old today

[Rui Maciel]

Today the GCC development team celebrates the 25th anniversary of the GNU
Compiler Collection.

Taken from:
http://gcc.gnu.org/ml/gcc/2012-03/msg00347.html

<quote>
When Richard Stallman announced the first public release of GCC in
1987, few could have imagined the broad impact that it has had. It
has prototyped many language features that later were adopted as part
of their respective standards -- everything from "long long" type to
transactional memory. It deployed an architecture-neutral automatic
vectorization facility, OpenMP, and Polyhedral loop nest optimization.
It has provided the toolchain infrastructure for the GNU/Linux
ecosystem used everywhere from Google and Facebook to financial
markets and stock exchanges. We salute and thank the hundreds
of developers who have contributed over the years to make
GCC one of the most long-lasting and successful free software projects
in the history of this industry.
</quote>


In your views, what has been GCC's main contribution to the world of
compilers?


Rui Maciel

[BGB]

On 3/22/2012 3:29 PM, Rui Maciel wrote:
> Today the GCC development team celebrates the 25th anniversary of the GNU
> Compiler Collection.
>
> Taken from:
> http://gcc.gnu.org/ml/gcc/2012-03/msg00347.html

<snip, quote>

> In your views, what has been GCC's main contribution to the world of
> compilers?

maybe, being free.

I vaguely remember a time when compilers tended to cost money, and
weren't exactly cheap.

GCC showed up in various forms (such as DJGPP, and later Cygwin and
MinGW), and in not much time, most previously non-free compilers (MSVC,
Watcom, ...) became freely available as well.


if not for GCC, maybe compilers would tend to still cost money?
either that, or maybe this trend was inevitable?

[Dmitry A. Kazakov]

On Sat, 24 Mar 2012 08:44:36 -0700, BGB wrote:
> GCC showed up in various forms (such as DJGPP, and later Cygwin and
> MinGW), and in not much time, most previously non-free compilers (MSVC,
> Watcom, ...) became freely available as well.
>
> if not for GCC, maybe compilers would tend to still cost money?
> either that, or maybe this trend was inevitable?

It was. The software market was (and is) unregulated. The big software
vendors were able to fund incredibly cost-intensive compiler
development form sales of other, far less expensive to develop,
software and services.

This started a race to the bottom and, in the end, destroyed the whole
market of compilers with all the compiler vendors who were not quick
enough to diversify their business. Those who did, walked away anyway.
Why would you keep an unprofitable department? You cannot yearn
anything for compilers now.

Consequently, there is no significant investments in compiler and
language research, of which effect the author of the article observed
as a "plateau." There is no mystery in it, no market means no
progress. Academic research very soon became irrelevant without an
input from the field, without industry hungry for fresh compiler
developers. So, here we are.

Was GCC responsible for that? No, its role was rather positive, to keep
some least diversity of compilers, to serve as an epitaph on the
tombstone...

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[comp...@is-not-my.name]

> On Sat, 24 Mar 2012 08:44:36 -0700, BGB wrote:
> > GCC showed up in various forms (such as DJGPP, and later Cygwin and
> > MinGW), and in not much time, most previously non-free compilers (MSVC,
> > Watcom, ...) became freely available as well.
> >
> > if not for GCC, maybe compilers would tend to still cost money?

They still do, once you realize there are computers other than PCs and
there are OS other than UNIX.

> > either that, or maybe this trend was inevitable?

On Linux/UNIX? Probably so given people expect free as in free and are
not used to paying for anything. Hard to figure pricing models for
that market, but the cheaper the better.

> It was. The software market was (and is) unregulated. The big software
> vendors were able to fund incredibly cost-intensive compiler
> development form sales of other, far less expensive to develop,
> software and services.

Yes but not necessarily only. Some of the compilers still cost a bundle and
since they're mature I think they're making all their money back several
times over. I don't have the numbers in front of me so my guess isn't any
worse than yours unless you do.

> This started a race to the bottom and, in the end, destroyed the whole
> market of compilers with all the compiler vendors who were not quick
> enough to diversify their business. Those who did, walked away anyway.
> Why would you keep an unprofitable department? You cannot yearn
> anything for compilers now.

This is not generally true. If you're talking about Intel x86 it's mostly
true. As you know Adacore still makes plenty of money. So does Green
Hills. So do others I haven't heard of.

It's not true about IBM at all on System Z. They sell compilers and make a
lot of money, it's probably all gravy now. I don't know if they make money
on compilers for POWER and AIX. There are even a few companies selling C/C++
compilers for System Z. It's not only IBM in the market, and people are
still spending money.

> Consequently, there is no significant investments in compiler and
> language research, of which effect the author of the article observed
> as a "plateau." There is no mystery in it, no market means no
> progress. Academic research very soon became irrelevant without an
> input from the field, without industry hungry for fresh compiler
> developers. So, here we are.

I don't think this is correct. Like many other things about the industry, it
has become a lot more focused and refined but I don't think there is no
market. And I don't think there is no innovation and no progress. Things
move along. There are several significant compiler companies. Not as many as in
the 1970s and not on as many platforms but there are still some doing a
pretty good business.

> Was GCC responsible for that? No, its role was rather positive, to keep
> some least diversity of compilers, to serve as an epitaph on the
> tombstone...

It's an epitaph on FSF's tombstone, with any luck!

[There's plenty of compiler work in embedded systems, too. ARM has
compilers that basically just generate intermediate code, and the
linker does sophisticated global optimization over the whole program.
-John]

[glen herrmannsfeldt]

BGB <cr8...@hotmail.com> wrote:

(snip)

> I vaguely remember a time when compilers tended to cost money, and
> weren't exactly cheap.

The design software for both Xilinx and Altera FPGAs, which among
other things includes VHDL and Verilog parsers, is now free, except
for the high-end devices. (Presumably like in the early days of
computing, supported by selling hardware.)

It wasn't always that way, and should be pretty much unrelated
to FSF and GCC.

For that matter, consider web browsers as HTML interpreters.

-- glen

[Dmitry A. Kazakov]

On Tue, 27 Mar 2012 09:27:03 -0000, comp...@is-not-my.name wrote:

> As you know Adacore still makes plenty of money.

First GNAT is GCC. Second AdaCore does not sell it. GNAT is free. AdaCore
sells support and an escape from the GPL-jail.

> So does Green Hills.

Yes, compilers for embedded systems are not completely dead. Just because
new processors come and die quicker than the process of suffocation fastens
its grip. In fact it is the BSP people are buying, not the compilers. And
for a given board there is normally only one compiler +/- GCC. This is not
yet a market. If it became one, it would suffer the same fate, the market
of PC compilers did. The point is that, as with the case of AdaCore,
embedded is more about selling services than about selling compilers.

> There are several significant compiler companies. Not as many as in
> the 1970s and not on as many platforms but there are still some doing a
> pretty good business.

How could it become less in the era of mobile computing, GPUs, concurrent,
networking systems? When computers are infesting everything except for
maybe door mats (yet to come)?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[See http://www.atekcompanies.com/whats-new/usb-kiosk-mat.aspx -John]

[Rui Maciel]

BGB wrote:

> On 3/22/2012 3:29 PM, Rui Maciel wrote:
>> Today the GCC development team celebrates the 25th anniversary of the GNU
>> Compiler Collection.
>>
>> Taken from:
>> http://gcc.gnu.org/ml/gcc/2012-03/msg00347.html
>
> <snip, quote>
>
>> In your views, what has been GCC's main contribution to the world of
>> compilers?
>
> maybe, being free.

But GCC isn't the only free compiler out there, and yet no other
compiler, paid or free, managed to attain the same level of
popularity. Couldn't it be possible that GCC's success is owed to
some determining factor other than price?

> I vaguely remember a time when compilers tended to cost money, and
> weren't exactly cheap.

There are still paid compilers out there. If I'm not mistaken, Intel sells
its compiler for around 600 euros.


Rui Maciel
[I think it's fair to say that GCC was the first free compiler that
generated code competitive with commercial compilers. -John]

[BGB]

On 3/27/2012 2:27 AM, comp...@is-not-my.name wrote:
>> On Sat, 24 Mar 2012 08:44:36 -0700, BGB wrote:
>>> GCC showed up in various forms (such as DJGPP, and later Cygwin and
>>> MinGW), and in not much time, most previously non-free compilers (MSVC,
>>> Watcom, ...) became freely available as well.
>>>
>>> if not for GCC, maybe compilers would tend to still cost money?
>
> They still do, once you realize there are computers other than PCs and
> there are OS other than UNIX.

I mostly am using and was thinking mostly about Windows.

in Windows land, many compilers proper are free (yes, Visual Studio is
not free, but one is paying more for the IDE than for the compiler
itself, which can be gained for free).

there are many GCC variants.

Watcom once cost money, but is now free.

...

>>> either that, or maybe this trend was inevitable?
>
> On Linux/UNIX? Probably so given people expect free as in free and are
> not used to paying for anything. Hard to figure pricing models for
> that market, but the cheaper the better.

again, on Windows.

there was a time when compilers cost money for both DOS and Windows,
but seemed to change with DJGPP and MinGW and so on being available.

tools/libraries for most scripting languages also tend to be freely
available by default.

>> It was. The software market was (and is) unregulated. The big software
>> vendors were able to fund incredibly cost-intensive compiler
>> development form sales of other, far less expensive to develop,
>> software and services.
>
> Yes but not necessarily only. Some of the compilers still cost a bundle and
> since they're mature I think they're making all their money back several
> times over. I don't have the numbers in front of me so my guess isn't any
> worse than yours unless you do.

well, one can ask:
what if MS were to charge for the Windows SDK?

most likely, people who might otherwise use it would just use MinGW instead.

now, what if there were no MinGW or Cygwin or similar around?

very possibly, people like MS can and would charge for the Windows SDK
(unless something like PCC or LCC or similar would have taken GCC's place).

>> This started a race to the bottom and, in the end, destroyed the whole
>> market of compilers with all the compiler vendors who were not quick
>> enough to diversify their business. Those who did, walked away anyway.
>> Why would you keep an unprofitable department? You cannot yearn
>> anything for compilers now.
>
> This is not generally true. If you're talking about Intel x86 it's mostly
> true. As you know Adacore still makes plenty of money. So does Green
> Hills. So do others I haven't heard of.
>
> It's not true about IBM at all on System Z. They sell compilers and make a
> lot of money, it's probably all gravy now. I don't know if they make money
> on compilers for POWER and AIX. There are even a few companies selling C/C++
> compilers for System Z. It's not only IBM in the market, and people are
> still spending money.

I think the issue here is that "big money" needs to be involved for
people to be anywhere near an IBM mainframe, so a little more money is
not asking a whole lot.


however, in PC land, something like Visual Studio can cost more than a
low-end PC, and many more of the developers are people without a huge
budget (such as people in their teens and 20s who are not actively
employed as a programmer), and these sort of people are much less likely
to pay so much for a piece of software.

in this case, there is also a lot more incentive for such people to make
things like this and make them freely available. even if they don't get
a lot of money, they may get a lot more recognition and status and "a
sense of community" and similar for having done so.


this property may matter much less in cases where the barrier to entry
is much higher, since if people have lots of money, they are much more
likely to be willing to spend it, and the relative payoff of making
things freely available is much lower ("popularity" and "a sense of
community" aren't really going to help keep a company going, but selling
a product will).

reasons though why a company might make something freely available
though could be to promote lock-in with their other products, or if
there is little or no market for the product.

>> Consequently, there is no significant investments in compiler and
>> language research, of which effect the author of the article observed
>> as a "plateau." There is no mystery in it, no market means no
>> progress. Academic research very soon became irrelevant without an
>> input from the field, without industry hungry for fresh compiler
>> developers. So, here we are.
>
> I don't think this is correct. Like many other things about the industry, it
> has become a lot more focused and refined but I don't think there is no
> market. And I don't think there is no innovation and no progress. Things
> move along. There are several significant compiler companies. Not as many as in
> the 1970s and not on as many platforms but there are still some doing a
> pretty good business.
>
>> Was GCC responsible for that? No, its role was rather positive, to keep
>> some least diversity of compilers, to serve as an epitaph on the
>> tombstone...
>
> It's an epitaph on FSF's tombstone, with any luck!

I don't think free software or open-source needs to go away, since it
does seem to have a fair amount of benefit in many areas.

granted, not everyone who believes in FOSS necessarily agrees with RMS
either though.

> [There's plenty of compiler work in embedded systems, too. ARM has
> compilers that basically just generate intermediate code, and the
> linker does sophisticated global optimization over the whole program.
> -John]

although not exactly the same, and for probably different reasons,
something vaguely similar is used a fair amount in my own stuff as well
(such as in the newer JIT for my scripting VM).

in many cases, the produced ASM code actually contains "requests", which
may in turn trigger the linker to call code generators for other pieces
of code (the request is itself encoded in the output via a call
instruction to a specially mangled name). the called generator will then
emit a piece of code specialized for handling this request.

I had idly considered the possibility of also allowing this to be done
at the level of the assembler, to essentially produce code which would
be "inlined", but thus far have not done so (this seems kind of like
more of a big nasty hack than doing it at link-time).

a technically cheaper/simpler option would be to allow the request to be
encoded instead using a jump instruction, relying on the fact that 2
direct jumps seem to be a bit faster than a call/return pair, but this
would disallow the generated code thunks from being reused (since each
thunk would need to return to a fixed address).

this could involve the linker "magically" transforming a call
instruction into a jump instruction (since, for example, on x86 both
CALL and JMP differ solely in the opcode byte).


as-is, the mechanism is a bit cheaper than a traditional function
call/return as:
values in both directions are typically passed in caller-defined
registers, or as immediate values (encoded into request signature);
typically, a mask value is provided to tell the specialized code
generator which registers it may safely use without needing to preserve
them;
they are easier to generate code for than a "proper" function call.

sometimes, it may be slightly more expensive though, such as when the
request is handled essentially by just marshaling the call into a
function call into C land.

typically, this is also used to implement things like:
getting/setting object fields;
calling methods;
calling many functions;
(sometimes) loading constant values (some constants may either depend on
run-time data, or otherwise have a value that is not a readily
determined constant during code generation);
...

another slight merit is that it allows things to be a little more
loosely coupled, since a the main codegen (compiling the script bytecode
to native code) doesn't need to know about the exact details of every
piece of machinery it interfaces with (nor is it necessary to write
"plug-ins" to interface these pieces of machinery with the code-gen).

however, there are potential merits for allowing codegen plugins as well
(rather than handling everything by plugging "request handlers" into the
linker).


sadly... using this mechanism at present would likely require writing a
custom static linker if I have any desire to be able to statically
compile my scripting language to native code (not currently possible).

[Hans-Peter Diettrich]

Rui Maciel schrieb:

> But GCC isn't the only free compiler out there, and yet no other
> compiler, paid or free, managed to attain the same level of
> popularity. Couldn't it be possible that GCC's success is owed to
> some determining factor other than price?

In former times it was common practice to use one compiler for
development, and another one for production. The development compiler
has to integrate nicely into the development system, with short
turn-around times, and has to provide the best diagnostics possible.
The production compiler instead has to provide the best optimization,
while diagnostics and turn-around times are quite unimportant.

> [I think it's fair to say that GCC was the first free compiler that
> generated code competitive with commercial compilers. -John]

Obviously it's more economic to maintain multiple code generators in a
common compiler framework, instead of writing and maintaining an
dedicated compiler for every target, as most isolated commercial or
hobby compiler writers did.

My experience with "highly optimizing" compilers, in detail MSC, sums
up in "the new version ejects less NOPs than the preceding one". This
may have changed nowadays, though...

DoDi

[comp...@is-not-my.name]

Dmitry wrote:

> compilers wrote

>
> > As you know Adacore still makes plenty of money.
>
> First GNAT is GCC. Second AdaCore does not sell it. GNAT is free. AdaCore
> sells support and an escape from the GPL-jail.

No, I think that is not accurate. Yes, GNAT is GCC, sortof,
eventually, maybe. But to get the "integrity assured" validated
compiler suite you have to pay, last time we heard, 20,000 USD for a
package of (I think) 5 seats. It's disingenous to say you're only
buying support, because Adacore owns the upstream and provides fixes
that GCC eventually adopts and there is no time frame for this. It's
not the same code, and it's not the same tools that GCC provides. At
the end of the day does anyone really think the sales of the "support"
aren't what's funding GNAT? I'm not sure how they get away with dual
licensing if the code is the same but IANAL. I am somebody who thinks
something is rotten in Denmark though. It would be a lot more honest
as far as I am concerned, to just say they're selling it. Escaping
from the GPL-jail is worth something, but you can't call that support.
It's called buying something. Come on, guys!

> > So does Green Hills.
>
> Yes, compilers for embedded systems are not completely dead. Just because
> new processors come and die quicker than the process of suffocation fastens
> its grip. In fact it is the BSP people are buying, not the compilers.

Is embedded all Green Hills and Aonix and the other Ada vendors do?
They are also offering UNIX and Windows targets and they are not free,
not by a long shot. There are another 2 or 3 Ada vendors that sell for
UNIX and Windows targets I found in a quick web search.

Intel sells Fortran and it is supposed to be excellent, because of
Intel's inside knowledge of its own architecture. The Linux versions
are usually free for academic use, but Windows has no free version and
no academic license. They also sell a C/C++ compiler.

If you look you can find a bunch more companies selling compilers.
Apparently there are still enough people around who don't like GCC even
without the GPL contamination who are willing to pay good money for a compiler.

> And for a given board there is normally only one compiler +/- GCC. This is
> not yet a market. If it became one, it would suffer the same fate, the
> market of PC compilers did. The point is that, as with the case of AdaCore,
> embedded is more about selling services than about selling compilers.

That's the way they position it, because of the GPL dishonesty. But I say if
you can't get the code free without paying for support (or waiting who knows
how long for fixes that may never come) then yes, they're selling it. This
kind of flim flam and hair splitting isn't helpful. You well know several
people have expressed interest on comp.lang.ada in buying a developer
license for a non-GPL GNAT and there was either dead silence or someone
saying Adacore is not interested in small fish, even without support.

> > There are several significant compiler companies. Not as many as in
> > the 1970s and not on as many platforms but there are still some doing a
> > pretty good business.
>
> How could it become less in the era of mobile computing, GPUs, concurrent,
> networking systems? When computers are infesting everything except for
> maybe door mats (yet to come)?

Because in the early days people paid for everything. It was only after UNIX
with a healthy dose of Stallman convinced the masses of the values of
socialism and putting their hands in everyone's pockets but not letting
anyone's hands in their pockets (funny how that works) people started being
a lot less willing to pay for compilers. Think of all the dozens of pre-PC
computers like the Atari, Commodore, TRS-80, the list goes on and on, there
were dozens of compilers sold for every platform and hundreds of
companies. Borland was built on that landscape.

There are less companies selling compilers now because of what I wrote above
and because the vast majority of the new platforms are using good old C++
(proprietary or otherwise) or Java or JVM languages and they can't sell that
stuff. The runtime and development tools are either given away for nothing to
encourage people to write code for those platforms or packaged just for the
vendor and aren't released at all. GPU stuff is all giveaway to get you to
buy their products. You can't say it's free, although technically it is,
because it's really part of the cost of buying and selling the platform. It
doesn't help you to have nVidia's SDK if it doesn't work on the other guy's
GPU platform. It's only valuable to you if you own nVidia's cards, etc.

[Ahem. In the early days software was all free. It wasn't even
possible to copyright it. Companies started selling it in the late
1960s partly because so realized there was a market for specialized
programs (the first was one that drew the flowcharts that managers
demanded from the code the programmers had already written), and
a legal settlement led IBM to unbundle their system software. But
the ancient free version of Fortran H still generates amazingly
good code. -John]

[Joshua Cranmer]

>>> In your views, what has been GCC's main contribution to the world of
>>> compilers?
>>
>> maybe, being free.
>
> But GCC isn't the only free compiler out there, and yet no other
> compiler, paid or free, managed to attain the same level of
> popularity. Couldn't it be possible that GCC's success is owed to
> some determining factor other than price?

GCC is effectively required for the Linux kernel, among other things,
which creates a surprisingly effective lock-in market considering only
free software is involved :-). Once GCC was established, it means that
any serious new compiler would have to both include most of GCC's
extensions, mirror its command line (to insert itself into most build
scripts easily), and get similar performance to be taken
seriously--which amounts to a very tall order. Of course, in the past
few years, the Clang/LLVM infrastructure has progressed well enough to
be able to tackle the hegemony of GCC.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

[BGB]

>>> compilers?
>>
>> maybe, being free.
>
> But GCC isn't the only free compiler out there, and yet no other
> compiler, paid or free, managed to attain the same level of
> popularity. Couldn't it be possible that GCC's success is owed to
> some determining factor other than price?

going from my limited experience, GCC was the first major compiler I saw
"putting up a good fight".

it came in the form of DJGPP at the time, which was an alternative to
what I was using before (TurboC), and much cheaper than the other option
(Watcom, at which IIRC my parents balked at the price).

I also saw LCC, but only ever saw it in a bare-bones form (it didn't
come with OS headers or libraries), and it seemed to produce fairly
naive output (and, IIRC at the time, not for the assembler I was using).


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).

and, to some extent, Visual Studio, but mostly because of the MSDNAA
thingy (didn't have to pay for it directly).


I remember looking at LCC again later, but at the time decided to write
my own C compiler based on my own code (I forget the exact reasons now).

my C compiler effort was based on the VM for my own language, but the C
compiler effort ran into significant difficulties regarding maintenance
and debugging, among other things.

more recently, more effort has been focused more on my scripting
language instead which, despite being ECMAScript based, still inherits a
fair amount from C, and some from C++ as well.

>> I vaguely remember a time when compilers tended to cost money, and
>> weren't exactly cheap.
>
> There are still paid compilers out there. If I'm not mistaken, Intel sells
> its compiler for around 600 euros.

yes, but I think they are mostly aiming for a special market:
people who want finely tuned high-performance output, and are willing to
pay for it.


I personally worry a little less about this though, given AFAICT there
is only around a 2x-3x raw performance difference between very naive
output (no optimizations or debug settings) and full compiler optimizations.

this, in turn, only really tends to make a big difference if the
performance is CPU-bound. if it is bound by something else, say, the
GPU, then other lines of optimization may make more sense (less worry
about using compiler optimizations for code that is only 1-4% of the
running time).

granted, a person can ask what the difference is between, say, MSVC or
GCC optimized output and ICC output, but I don't think it is likely to
be all that drastic (looking around, it seems to be generally closer to
around 20%).


actually, I do a lot of stuff, in general, that is arguably just "bad"
from a performance POV (such as using a lot of use of dynamic
type-checking in many places, ...), but then again, this code is not a
significant time waster (a lot of this code has ended up a bit
micro-optimized though, like a lot of "evil tricks" in the type-checking
predicate functions).

sometimes convenience may matter more, like having compiler logic or a
network protocol being based on dynamic types may turn out to be a bit
more convenient than using statically-typed logic.

it is not strictly "one or the other" though, as most often, dynamic
types are unnecessary (and would waste time and make debugging harder),
but where they are useful, they are very useful.

> Rui Maciel
> [I think it's fair to say that GCC was the first free compiler that
> generated code competitive with commercial compilers. -John]

yes, very possibly...

now, one can argue about LLVM, but where was LLVM 15 years ago? it
didn't exist yet.

so, timing may be an important factor to consider as well, in addition
to things like price, ideologies, the use of the GNU toolchain for
developing Linux, ...

[Hans-Peter Diettrich]

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.

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.

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.

DoDi

[Dmitry A. Kazakov]

On Thu, 29 Mar 2012 12:30:09 -0000, comp...@is-not-my.name wrote:

> You well know several
> people have expressed interest on comp.lang.ada in buying a developer
> license for a non-GPL GNAT and there was either dead silence or someone
> saying Adacore is not interested in small fish, even without support.

And this will never happen. It is not profitable to do (unless AdaCore were
able to generate some sort of irrational cult as Apple did).

>>> There are several significant compiler companies. Not as many as in
>>> the 1970s and not on as many platforms but there are still some doing a
>>> pretty good business.
>>
>> How could it become less in the era of mobile computing, GPUs, concurrent,
>> networking systems? When computers are infesting everything except for
>> maybe door mats (yet to come)?
>
> Because in the early days people paid for everything. It was only after UNIX
> with a healthy dose of Stallman convinced the masses of the values of
> socialism and putting their hands in everyone's pockets but not letting
> anyone's hands in their pockets (funny how that works) people started being
> a lot less willing to pay for compilers.

It is not Stallman's fault and it is not socialism. Socialism is when the
state re-distributes wealth. In the case of compilers, it is not state but
large monopolists at which mercy compilers are left. Customer money play no
role whatsoever, because developing is funded from other sources and for
reasons absolutely unrelated to the merits of a particular programming
language, quality of the generated code etc.

I don't care which system is worse, the effect is just same: stagnation.

> [Ahem. In the early days software was all free. It wasn't even
> possible to copyright it. Companies started selling it in the late
> 1960s partly because so realized there was a market for specialized
> programs (the first was one that drew the flowcharts that managers
> demanded from the code the programmers had already written), and
> a legal settlement led IBM to unbundle their system software. But
> the ancient free version of Fortran H still generates amazingly
> good code. -John]

Yes indeed. It was because the software was unusable without the vendor's
hardware. The hardware was incompatible and vendors were competing each
other. This made them interested in putting better software in the package.
That era of great compilers is gone. It is worth to remember brilliant
DEC's FORTRAN-IV, C and Ada compilers.

[BGB]

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]

[BGB]

yeah.

my own compiler effort (even if now mostly reduced to a code
parsing/processing tool, rather than being used to actually compile
code) has to itself deal with a lot of both GCC and MSVC extensions.


until one deals with the issue, it is likely easy to underestimate how
many extensions and edge-cases may be lurking in various OS headers:
GCC has __attribute__ and friends;
MSVC has __declspec and friends;
then, there are a number of generally shared but non-standard keywords
one may also end up running into ("__cdecl", "__stdcall", "__fastcall",
"__inline", ...);
as well as special preprocessor directives ("#import", "#include_once",
"#include_next", ...);
macros using "/##*" and "*##/" to implement conditional comments;
macro definitions and invocations spread over multiple lines without
using '\' (AFAIK, the standard requires '\' for multi-line preprocessor
stuff, but the compilers seem to relax this in certain cases, typically
involving macro parameter lists, 1);
little things, like omitting the names for struct members (2);
GCC allows pointer arithmetic with "void *" pointers;
little things, like allowing whitespace before "#" (3);
...

1: stuff like:
#define FOO(x, y
) BAR(x,
y)
which seems to be assumed to work by the headers, but AFAIK is not valid
as per the C standards (more so, whether or not this will parse as above
depends on BAR also being a macro).

2:
struct foo_s {
struct bar_s;
struct baz_s;
int;
char *;
};
structs end up essentially directly inlined, unnamed basic fields are
presumably inaccessible padding.

3:
#ifdef FOO
#include <foostuff.h> //not strictly legal AFAIK
#endif
versus:
#ifdef FOO
# include <foostuff.h>
#endif


both GCC and MSVC may try to include inline assembler in inline
functions and similar as well, ...

I remember encountering a good deal more than this, but I can't remember
all of it at the moment.

never-mind the (technically legal) wide variety of orderings which
declaration keywords may appear in ("int unsigned * const volatile
foo;"), and all of the places where those "__attribute__" keywords may
appear in a declaration (vs, say, "__declspec", which at least so
happens to fairly consistently appear before the declaration, vs, say,
"int foo() __attribute__((...));").

maybe (yes, nested functions in GCC, ...):
"static int foo() { int bar() { ... } bar(); }".

about the only thing I really remember not encountering in headers are
trigraphs and K&R style declarations, which are ironically both required
to be supported by the C standard.


although, in a way, all this does help point out all of these nice
little features which someone somewhere was probably like "wouldn't it
be so nice if the compiler allowed us to write X?..." (but, it is a
little harder to know what all features exist).


to some extent, my tools also emulate both GCC and MSVC command-line
arguments, although generally, ignoring everything that the tool doesn't
care about, also works.

granted, it is much less of an issue probably in my case, since a "code
processing tool" doesn't really need to faithfully emulate the compilers
anywhere near as much as a drop-in compiler replacement would (it mostly
just has to deal with whatever it might run into while processing headers).

[Anton Ertl]

Rui Maciel <rui.m...@gmail.com> writes:
>[I think it's fair to say that GCC was the first free compiler that
>generated code competitive with commercial compilers. -John]

I had an internship at HP in the late 1980s. One of the people there
commented that, when gcc came out, it's code was (IIRC) 30% faster
than that of HPs compilers (for the 68k-based HP9000 computers running
HP/UX); a year later HPs compiler had caught up quite a bit. My guess
is that HP's compiler was PCC-based, and that optimization did not play
a big role in the Unix market until the arrival of RISCs and GCC.
Nowadays it plays too big a role for my taste (I prefer my programs to
work as intended).

- anton
--
M. Anton Ertl
an...@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/
[Where are the Real Fortran programmers now that we need them? -John]

[BGB]

On 3/30/2012 1:33 PM, BGB wrote:

<snip>

> 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]

yes, granted.

me wandering off pretty far from the original topic here, oh well.


I can imagine bigger issues though:
be lazy, port to C++/CLI, live with the issue that it wont work on Mono;
or, having to largely re-implement the VM in C# (would likely be a huge
pain, and would likely almost be better off as a largely ground-up
reimplementation).

the type-system shouldn't be as much of a challenge, since technically
.NET can do vaguely similar stuff to what my typesystem does, and other
parts of the design were partly inspired by C# anyways (the static type
hierarchy is fairly similar).

a few major influences: ECMAScript, ActionScript, Java, C#, C, and C++,
as well as lesser influences: Scheme, Self, Erlang, ... the language
roughly implements ECMA-262, but deviates in some cases.


similarly, BGBScript already supports Class/Instance OO, references,
properties, ...

note: it also still has Prototype-OO, internally a "hybrid" object model
is used. externally, this is exposed similar to in ActionScript3,
whereby using a "dynamic" modifier on a class declaration allows
addition of new fields at runtime (otherwise, a fixed layout is used).
objects created ex-nihilo are implicitly both dynamic and lack a parent
class (internally, there are about 3 different "types" of object, with
the "dynamic class" case being a class/instance object daisy-chained
with a prototype/"dictionary" object, which is apparently different from
how it works in ActionScript, but then again, I also implemented
interfaces via a large hash-table as well...).


note: there is a partial split between static and dynamic types, as the
"static type system" vaguely represents a Java/C# style type-system, and
the "dynamic type system" uses a different set of types (so, it is not
strictly 1:1, unlike Java or C#).

hence:
var i:int; //integer variable (32-bit range)
var j:fixnum; //fixnum variable (currently 28 or 48 bit range)
car k:long; //long variable (64-bit range)
var v; //variant (default type)

v=i; //may convert to fixnum or a boxed int (depending on range)
v=j; //copied directly (may be slightly cheaper in some cases)
v=k; //currently converts to boxed long

note that type coercion works more like C, with most types converting
freely when possible, although potentially implicit down-casting could
be made to generate a warning.

var b:bool;
b=i; //"warn: implicit type conversion from int to bool" or similar.

variant is not exactly the same as "object" in C#, differing mostly in
fine details (in certain cases, type-inference is allowed to convert it
to a static type, although it will always be a variant/reference if used
as an explicit storage type).

note that the default array type is "variant[]", and arrays will be this
type except in certain cases (creation via "new type[size]", array-type
suffixes, or being used to initialize a variable with a declared array
type "var arr:int[]=[1,2,3];").


struct Foo {
var obj:variant; //will not be inferred
var obj2; //likewise
}

note: structs have similar behavior to C#, and are pass-by-value /
pass-by-copy. there is also "value_class", which is conceptually similar
(but is a full class type, sort of like in C++, but lacking MI).
internally, structs and value-classes are aliases (but, they are not
strictly equivalent regarding their semantics).

note: the same basic mechanism is used to access C structs, and could
potentially be extended to support C++ classes, but more work would be
needed for this (mostly for supporting vtables and similar, but it has
not been a high priority).

extra note: "dynamic value_class" is not allowed, maybe for obvious
enough reasons. value-classes have a fixed memory layout.


example:
value_class Foo {
...
}

var obja:Foo; //value class
var objb:*Foo; //pointer to value class
var objc:Foo; //value class

obja=new Foo(); //init obja (1)
objb=&obja; //pointer to obja (2)
objc=obja; //copy of obja (may invoke copy-constructor, 3)

...

note 1: value classes are implemented differently than in C++ or
similar, in that they are still handled as reference-types (to heap
allocated instances). their primary difference is that they are subject
to copy/delete semantics (they are deleted when they go out of scope,
which will call the destructor if one exists). granted, this isn't
particularly efficient, but whatever.

note 2: currently, there is no construct to directly initialize a
"pointer to a value-class", but something like "new *Foo()" or similar
is a possible syntax. technically, "&obja" creates a reference, but
references may be implicitly converted to pointers.

note 3: functionally similar to "objc=new Foo(obja);" if a valid
constructor exists (otherwise, a raw copy is made).


side node, the syntax:
int i;
string str;
...
is supported, just it is harder to claim that the language is still an
ECMAScript variant, if one is sitting around using lots of declarations
which are clearly a different style from ECMAScript. these cases are
parsed more like in Java/C# than like in C or C++ though. also, unlike C
or C++, pointers are declared with '*' in prefix position "*int pi;"
rather than "int *pi;", this change having been made to avoid
potentially ambiguous syntax (for a similar reason, the language doesn't
use C style cast syntax, instead using a different syntax: "x as type"
and "x as! type").

by convention, I am typically staying closer to ECMAScript style.


a bigger challenge (if trying to produce CIL) could be the scoping
model, where my language uses a scoping model partly influenced by Self,
which is relatively uncommon and lacks .NET support.

lesser worries are that .NET lacks direct fixnum and flonum analogues,
and they would instead have to be implemented via boxed types, which
would be more expensive (a boxed type being generally a heap-allocated
object, vs a value encoded directly into the pointer).

this is also one point (among others) where my language fails regarding
ECMA-262 conformance: I don't default to using double for numbers,
because I would have to box doubles, and this would be expensive. so,
cheaper fixnums and flonums are used, but flonums are considerably less
accurate than a double (on 32-bit targets, they are a 32-bit float with
the low-order bits shaved off, and on 64-bit targets is a 64-bit double
with low-order bits shaved).


luckily, I have no plans to port to .NET, and am not at present all that
concerned even with making a nice C#/BS interface.


likely higher priorities:
finish implementing the new JIT / native-compiler;
implement some good way to directly produce (native friendly) DLLs
without needing to first generate and compile C glue-code (IOW: a custom
static linker);
...

but, as such, these are still not terribly high priorities for my
project as a whole.

[Joe keane]

In article <12-0...@comp.compilers>,

[moderator] wrote:
>[I think it's fair to say that GCC was the first free compiler that
>generated code competitive with commercial compilers. -John]

I think i could make a fair argument for PCC.

And with Unix they say: of course; the compiler is part of the operating
system; who in the hell would not do that?
[Having looked at PCC in considerable detail, I can say that it generated
adequate code for a PDP-11, lousy code for a Vax or anything else with a
lot of registers. It treated the registers as a stack, and the only
way a value got saved in a register was either an explicit register
declaration, or some very simple peephole optimizations. -John]

[mev]

> I had an internship at HP in the late 1980s. One of the people there
> commented that, when gcc came out, it's code was (IIRC) 30% faster
> than that of HPs compilers (for the 68k-based HP9000 computers running
> HP/UX); a year later HPs compiler had caught up quite a bit. My guess
> is that HP's compiler was PCC-based, and that optimization did not play
> a big role in the Unix market until the arrival of RISCs and GCC.

I worked on HP's 68K compilers from 1986 to 1992, particularly C and
Fortran front ends. These compilers were indeed PCC based.

We did optimization improvements including support for Dragon floating
point accelerator in HP-UX 6.5 (1988), peephole optimizations, adding
new inliner and some loop optimizations. We also updated front ends
to support ANSI C and features from upcoming Fortran 90 standard.
There was also some work to improve strcmp/strcpy as they played
heavily into Dhrystone 1.0. I still have the HP-UX 6.5 T-shirt with
release goals of >8 MIPS.

The performance emphasis came more from competitive positioning
against Sun and correlation with GCC introduction would be
coincidental in my recall. PA-RISC, SPARC and MIPS were coming on the
scene also with optimization emphasis.

We were aware of GCC but more as an interesting curiosity than
competitively. I also was at Denver C++ conference in October 1988
when Michael Tiemann presented what was first called GNU C++ but
became G++.

Mike Vermeulen

[Marco]

On Thursday, March 22, 2012 3:29:17 PM UTC-7, Rui Maciel wrote:

> In your views, what has been GCC's main contribution to the world of
> compilers?

It set the bar higher for compiler quality.

We now purchase compilers and associated environments when they have significant added value over GCC.

[Georg Bauhaus]

On 29.03.12 14:30, comp...@is-not-my.name wrote:
>>> As you know Adacore still makes plenty of money.
>>
>> First GNAT is GCC. Second AdaCore does not sell it. GNAT is free. AdaCore
>> sells support and an escape from the GPL-jail.
>

> No, I think that is not accurate. [...] Escaping from the

> GPL-jail is worth something, but you can't call that support. It's
> called buying something. Come on, guys!

Robert Dewar, President and CEO of AdaCore, has said this, at FOSDEM 2012:

"AdaCore is a successful company totally based on Free Software (all the
software we sell is licensed under the GPL, or other free software licenses)."
^^^^
http://fosdem.org/2012/interview/robert-dewar

The video of a presentation at Fosdem 2012 has few more remarks.
To find it, start a search: "robert dewar at fosdem 2012 video"

I'd guess that AdaCore has found an interpretation of "sell" that
matches the legal, commercial, and social requirements of doing
business and paying taxes.