From mboxrd@z Thu Jan 1 00:00:00 1970 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Brantley Coile In-reply-to: Date: Sat, 28 Nov 2015 02:40:31 -0500 Content-transfer-encoding: quoted-printable Message-id: <0962EE36-1765-440C-816F-90DEF0A5720D@me.com> References: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 794868e4-ead9-11e9-9d60-3106f5b1d025 Great point. And you actually don=E2=80=99t meet the minimum requirement = for snarky messages. You argue the the large compilers are due to the increase in the = complexity of the specification and the complexities of generating code = for the Intel instruction set. To some extent you are correct. A modern = C compiler would be larger than a PDP-11 compiler. In fact, I would = argue it should be about twice the size of the PDP compiler. I=E2=80=99m kind of cheating when I say that, because I know for a fact = that a ANSI C compiler would be that much larger because that=E2=80=99s = about the size of the Plan 9 C compiler compared to the PDP-11 compiler. = The 7th Edition C compiler was about 12,000 lines. Plan9=E2=80=99s = compiler for the 64 bit x86 instruction set is 22,000 lines of source. One could argue that the Plan 9 C compiler lacks the modern = optimizations that the other compilers have. This would be true. But I = would argue that almost all of those optimizations are either not needed = because the coder could have optimized his code in the first place, or = are way past the point of diminishing returns. So, I would say that = those optimization fill a much needed gap. Niklaus Wirth pointed out that the best characteristic of a language = used to create very efficient programs is predictability. This is = especially true for the modern architectures. We are much smarter than = any compiler will ever be and the knowledge of the micro architecture is = required to write the fastest code. (It doesn=E2=80=99t really change = that fast over the years.) The programmer does the work. That = predictability is best delivered when the compiler only optimized = inefficiencies it generates and not try to outsmart the programmer. I for one really enjoyed your point.=20 Brantley > On Nov 28, 2015, at 1:42 AM, da Tyga wrote: >=20 > I have been following this discussion about the C compiler and can no = longer stop myself from making a (snarky?) comment. >=20 > The K&R standard for C was very much written when the C language was a = higher than assembler language for the PDP-11 (at least that's how I = became acquainted with it back in 1976). Most of us, in those days, = welcomed something that was more high level than macro-assembler and yet = amenable to writing operating systems and utilities (unlike FORTRAN, = ALGOL and COBOL of that era). Many of us would use the -s switch to = check the generated assembler code and in some cases even modify the = assembler code for selected functions to get exactly the desired result. >=20 > The PDP-11 had a rather simple instruction set, thus the compiler = produced relatively predictable code. The undefined behaviours in many = cases meant that at least on the PDP-11 we would know what to expect. = It was only once code was ported to other systems that these assumptions = started getting sorely tested. >=20 > Fast forward to present time, we have a bloated C standard and even = more bloated C++ standards. The target instruction sets are rich with = lots of special case instructions; out of sequence execution; = multi-level caches add further constraints. So today's compilers need = to analyse complex source code to run with good performance on extremely = complex targets. We shouldn't forget that in the case of the x86 family = the compilers need to optimise for an ever evolving instruction set and = retain backward compatibility across earlier variants. >=20 >=20 > On 28 November 2015 at 12:01, erik quanstrom = wrote: > > Funny, but actually I was wondering if there is any subtle issue in = the > > standards of the C language that makes it somehow hard to implement. > > For example I've met a few times weird implementations of libraries = and > > frameworks dictated by broken standards: once they are in, they can = never > > be removed due to backward compatibility. I thought that Charles = (that also > > implemented the Limbo compiler) might have referenced these kind of = issues > > in his pun. >=20 > i think the simple answer is: no. but many folks just love = complexity, and are > determined to find it. if you give such a person one problem, they'll = come back > with two problems. i call these folks complicators. don't be a = complicator. >=20 > (i have to remind myself this from time to time.) >=20 > - erik >=20 >=20