From mboxrd@z Thu Jan 1 00:00:00 1970 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 From: Ryan Gonzalez Date: Sat, 28 Nov 2015 14:13:07 -0600 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>, da Tyga Message-ID: <66535EFF-39F3-4BEE-9913-507DF4E660A7@gmail.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 794f44e8-ead9-11e9-9d60-3106f5b1d025 On November 28, 2015 12:42:25 AM CST, da Tyga wrot= e: >I have been following this discussion about the C compiler and can no >longer stop myself from making a (snarky?) comment. > If you thing this is snarky, you've never visited the Final Fantasy XV bo= ard on GameFAQs! ;) >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. > >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. > >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.=20 >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. > I think the issue is trying to fix a broken problem. Perfect compatibilit= y is pretty much impossible, but most attempts done to fix it just shift = the pain to somewhere else. What's the quote about complexity not disappe= aring, just moving around? I prefer languages that prefer correctness to perfect, cross-platform API= s that consist of 2000 functions, and no one knows what the hell half of = them do. > >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. >> >> 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. >> >> (i have to remind myself this from time to time.) >> >> - erik >> >> --=20 Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. CURRENTLY LISTENING TO: The Key We've Lost (Xenoblade Chronicles X)