* [9fans] Compiling ken-cc on Linux @ 2015-11-25 17:10 Vasudev Kamath 2015-11-25 17:15 ` Ryan Gonzalez 2015-11-26 12:10 ` Charles Forsyth 0 siblings, 2 replies; 45+ messages in thread From: Vasudev Kamath @ 2015-11-25 17:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Hi, I'm trying to compile ken-cc from ¹. Its giving me following error cc -c -m32 -g -O -I/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include -I/home/vasudev/Documents/C_programming/compilers/9-cc/include -DLINUX_386 -I../cmd/ 9obj.c In file included from /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0, from 9obj.c:5: /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" ^ 9obj.c:8:22: fatal error: 9c/9.out.h: No such file or directory compilation terminated. mk: cc -c -m32 ... : exit status=exit(1) mk: for j in ... : exit status=exit(1) I can't find 9c under src/cmd folder. Any hints on how to get it compiled?. Cheers, ¹ https://bitbucket.org/plan9-from-bell-labs/9-cc/overview ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-25 17:10 [9fans] Compiling ken-cc on Linux Vasudev Kamath @ 2015-11-25 17:15 ` Ryan Gonzalez 2015-11-25 17:24 ` Vasudev Kamath ` (2 more replies) 2015-11-26 12:10 ` Charles Forsyth 1 sibling, 3 replies; 45+ messages in thread From: Ryan Gonzalez @ 2015-11-25 17:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1455 bytes --] See https://bitbucket.org/plan9-from-bell-labs/9-cc/issues/1/problems-building-under-x64-linux for some tips on fixing various errors you may encounter, including this one. (I opened that issue like 8 months ago...) On Wed, Nov 25, 2015 at 11:10 AM, Vasudev Kamath <vasudev@copyninja.info> wrote: > > Hi, > > I'm trying to compile ken-cc from ¹. Its giving me following error > > cc -c -m32 -g -O > -I/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include > -I/home/vasudev/Documents/C_programming/compilers/9-cc/include -DLINUX_386 > -I../cmd/ 9obj.c > In file included from > /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0, > from 9obj.c:5: > /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and > _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] > # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use > _DEFAULT_SOURCE" > ^ > 9obj.c:8:22: fatal error: 9c/9.out.h: No such file or directory > compilation terminated. > mk: cc -c -m32 ... : exit status=exit(1) > mk: for j in ... : exit status=exit(1) > > I can't find 9c under src/cmd folder. Any hints on how to get it > compiled?. > > Cheers, > > ¹ https://bitbucket.org/plan9-from-bell-labs/9-cc/overview > > -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ [-- Attachment #2: Type: text/html, Size: 2363 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-25 17:15 ` Ryan Gonzalez @ 2015-11-25 17:24 ` Vasudev Kamath 2015-11-26 12:08 ` Charles Forsyth 2015-11-27 16:50 ` Vasudev Kamath 2015-11-27 18:11 ` trebol 2 siblings, 1 reply; 45+ messages in thread From: Vasudev Kamath @ 2015-11-25 17:24 UTC (permalink / raw) To: Ryan Gonzalez; +Cc: Fans of the OS Plan 9 from Bell Labs Ryan Gonzalez <rymg19@gmail.com> writes: > See > https://bitbucket.org/plan9-from-bell-labs/9-cc/issues/1/problems-building-under-x64-linux > for some tips on fixing various errors you may encounter, including > this one. (I opened that issue like 8 months ago...) Thanks Ryan, I will follow this. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-25 17:24 ` Vasudev Kamath @ 2015-11-26 12:08 ` Charles Forsyth 0 siblings, 0 replies; 45+ messages in thread From: Charles Forsyth @ 2015-11-26 12:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 632 bytes --] That copy of the compilers was changed quite a bit by someone else, and I only belatedly realised that. I'll try to resurrect that one, since it would help me keep the Plan 9 and Inferno compilers in sync, as well. On 25 November 2015 at 17:24, Vasudev Kamath <vasudev@copyninja.info> wrote: > Ryan Gonzalez <rymg19@gmail.com> writes: > > > See > > > https://bitbucket.org/plan9-from-bell-labs/9-cc/issues/1/problems-building-under-x64-linux > > for some tips on fixing various errors you may encounter, including > > this one. (I opened that issue like 8 months ago...) > > Thanks Ryan, I will follow this. > > [-- Attachment #2: Type: text/html, Size: 1167 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-25 17:15 ` Ryan Gonzalez 2015-11-25 17:24 ` Vasudev Kamath @ 2015-11-27 16:50 ` Vasudev Kamath 2015-11-27 16:59 ` Ryan Gonzalez 2015-11-27 18:11 ` trebol 2 siblings, 1 reply; 45+ messages in thread From: Vasudev Kamath @ 2015-11-27 16:50 UTC (permalink / raw) To: Ryan Gonzalez; +Cc: Fans of the OS Plan 9 from Bell Labs Hi Ryan, Ryan Gonzalez <rymg19@gmail.com> writes: > See > https://bitbucket.org/plan9-from-bell-labs/9-cc/issues/1/problems-building-under-x64-linux > for some tips on fixing various errors you may encounter, including > this one. (I opened that issue like 8 months ago...) I followed your reported issue. I could fix first 2 points but I get different error after that. (cd src/libmath; mk all) /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmath.a doesn't exist: assuming it will be an archive cc -c -m32 -g -O -I/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include -I/home/vasudev/Documents/C_programming/compilers/9-cc/include -DLINUX_386 blas.c In file included from /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0, from blas.c:1: /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" ^ In file included from /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:19:0, from blas.c:1: /home/vasudev/Documents/C_programming/compilers/9-cc/include/mathi.h:59:12: error: expected identifier or ‘(’ before ‘sizeof’ extern int isnan(double); ^ mk: cc -c -m32 ... : exit status=exit(1) mk: for j in ... : exit status=exit(1) I tried to find sizeof in mathi.h but I can't really find anything. (Yeah there is no sizeof in either mathi.h or related files). I'm unsure what the error is indicating. Any idea on how to proceed further?. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-27 16:50 ` Vasudev Kamath @ 2015-11-27 16:59 ` Ryan Gonzalez 2015-11-27 17:16 ` Vasudev Kamath 0 siblings, 1 reply; 45+ messages in thread From: Ryan Gonzalez @ 2015-11-27 16:59 UTC (permalink / raw) To: Vasudev Kamath; +Cc: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 2011 bytes --] Try going to the top of mathi.h and putting: #undef isnan #undef isinf Stupid macros that don't look like macros. On November 27, 2015 10:50:20 AM CST, Vasudev Kamath <vasudev@copyninja.info> wrote: > >Hi Ryan, > >Ryan Gonzalez <rymg19@gmail.com> writes: >> See >> >https://bitbucket.org/plan9-from-bell-labs/9-cc/issues/1/problems-building-under-x64-linux >> for some tips on fixing various errors you may encounter, including >> this one. (I opened that issue like 8 months ago...) > >I followed your reported issue. I could fix first 2 points but I get >different error after that. > >(cd src/libmath; mk all) >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmath.a >doesn't exist: assuming it will be an archive >cc -c -m32 -g -O >-I/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include >-I/home/vasudev/Documents/C_programming/compilers/9-cc/include >-DLINUX_386 blas.c >In file included from >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0, > from blas.c:1: >/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and >_SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] ># warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use >_DEFAULT_SOURCE" > ^ >In file included from >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:19:0, > from blas.c:1: >/home/vasudev/Documents/C_programming/compilers/9-cc/include/mathi.h:59:12: >error: expected identifier or ‘(’ before ‘sizeof’ > extern int isnan(double); > ^ >mk: cc -c -m32 ... : exit status=exit(1) >mk: for j in ... : exit status=exit(1) > >I tried to find sizeof in mathi.h but I can't really find >anything. (Yeah there is no sizeof in either mathi.h or related >files). > >I'm unsure what the error is indicating. Any idea on how to proceed >further?. -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. [-- Attachment #2: Type: text/html, Size: 2609 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-27 16:59 ` Ryan Gonzalez @ 2015-11-27 17:16 ` Vasudev Kamath 2015-11-27 18:24 ` Ryan Gonzalez 0 siblings, 1 reply; 45+ messages in thread From: Vasudev Kamath @ 2015-11-27 17:16 UTC (permalink / raw) To: Ryan Gonzalez; +Cc: Fans of the OS Plan 9 from Bell Labs Ryan Gonzalez <rymg19@gmail.com> writes: > Try going to the top of mathi.h and putting: > > #undef isnan > #undef isinf > > Stupid macros that don't look like macros. That worked. Even I didn't realize those as macros. But now I land in new error. /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" ^ In file included from /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:19:0, from fdlibm/fdlibm.h:2, from fdlibm/s_isnan.c:20: fdlibm/s_isnan.c:22:6: error: expected identifier or ‘(’ before ‘sizeof’ int isnan(double x) ^ mk: cc -c -m32 ... : exit status=exit(1) mk: for j in ... : exit status=exit(1) So I went and put #undef isnan again before #include "fdlibm.h" in s_isnan.c and now I stop at a new error, again not mentioned in your reported issue. Posix.c: In function ‘myctime’: Posix.c:9:9: warning: implicit declaration of function ‘ctime’ [-Wimplicit-function-declaration] return ctime(&t); ^ Posix.c:9:9: warning: return makes pointer from integer without a cast [-Wint-conversion] cc -m32 -o o.out ar.o Posix.o /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmach.a /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libbio.a /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/lib9.a ar.o: In function `page': /home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/iar/ar.c:1120: warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp' /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmach.a(obj.o):(.rodata+0x198): undefined reference to `_is9' /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmach.a(obj.o):(.rodata+0x19c): undefined reference to `_read9' collect2: error: ld returned 1 exit status mk: cc -m32 ... : exit status=exit(1) mk: for j in ... : exit status=exit(1) mk: for j in ... : exit status=exit(1) I guess this is because of commenting out 9obj.c from compilation. So I modified 9obj.c, below is the patch vasudev@rudra:~/Documents/C_programming/compilers/9-cc$ hg diff src/libmach/obj.c diff -r 65fb8bb56c59 src/libmach/obj.c --- a/src/libmach/obj.c Thu Apr 23 11:11:38 2015 +0100 +++ b/src/libmach/obj.c Fri Nov 27 22:44:29 2015 +0530 @@ -24,14 +24,14 @@ int _is5(char*), _is6(char*), _is8(char*), - _is9(char*), + /* _is9(char*), */ _isk(char*), _isq(char*), _isv(char*), _read5(Biobuf*, Prog*), _read6(Biobuf*, Prog*), _read8(Biobuf*, Prog*), - _read9(Biobuf*, Prog*), + /* _read9(Biobuf*, Prog*), */ _readk(Biobuf*, Prog*), _readq(Biobuf*, Prog*), _readv(Biobuf*, Prog*); @@ -63,7 +63,7 @@ /*[ObjSparc64]*/ {0, 0,}, /*[ObjAmd64]*/ "amd64 .6", _is6, _read6, /*[ObjSpim]*/ {0, 0,}, - /*[ObjPower64]*/ "power64 .9", _is9, _read9, + /*[ObjPower64]*/ /* "power64 .9", _is9, _read9, */ /*[Maxobjtype]*/ 0, 0 }; That took compilation further but now it breaks at point 4 in your issue. I hope I won't encounter more new issues :-). Cheers, ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-27 17:16 ` Vasudev Kamath @ 2015-11-27 18:24 ` Ryan Gonzalez 2015-11-29 9:41 ` Vasudev Kamath 0 siblings, 1 reply; 45+ messages in thread From: Ryan Gonzalez @ 2015-11-27 18:24 UTC (permalink / raw) To: Vasudev Kamath; +Cc: Fans of the OS Plan 9 from Bell Labs On November 27, 2015 11:16:02 AM CST, Vasudev Kamath <vasudev@copyninja.info> wrote: >Ryan Gonzalez <rymg19@gmail.com> writes: > >> Try going to the top of mathi.h and putting: >> >> #undef isnan >> #undef isinf >> >> Stupid macros that don't look like macros. > >That worked. Even I didn't realize those as macros. But now I land in >new error. > >/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and >_SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] ># warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use >_DEFAULT_SOURCE" > ^ >In file included from >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:19:0, > from fdlibm/fdlibm.h:2, > from fdlibm/s_isnan.c:20: >fdlibm/s_isnan.c:22:6: error: expected identifier or ‘(’ before >‘sizeof’ > int isnan(double x) > ^ >mk: cc -c -m32 ... : exit status=exit(1) >mk: for j in ... : exit status=exit(1) > >So I went and put #undef isnan again before #include "fdlibm.h" in >s_isnan.c and now I stop at a new error, again not mentioned in your >reported issue. > >Posix.c: In function ‘myctime’: >Posix.c:9:9: warning: implicit declaration of function ‘ctime’ >[-Wimplicit-function-declaration] > return ctime(&t); > ^ >Posix.c:9:9: warning: return makes pointer from integer without a cast >[-Wint-conversion] >cc -m32 -o o.out ar.o Posix.o >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmach.a >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libbio.a >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/lib9.a > >ar.o: In function `page': >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/iar/ar.c:1120: >warning: the use of `mktemp' is dangerous, better use `mkstemp' or >`mkdtemp' >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmach.a(obj.o):(.rodata+0x198): >undefined reference to `_is9' >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libmach.a(obj.o):(.rodata+0x19c): >undefined reference to `_read9' >collect2: error: ld returned 1 exit status >mk: cc -m32 ... : exit status=exit(1) >mk: for j in ... : exit status=exit(1) >mk: for j in ... : exit status=exit(1) > >I guess this is because of commenting out 9obj.c from compilation. So I >modified 9obj.c, below is the patch > >vasudev@rudra:~/Documents/C_programming/compilers/9-cc$ hg diff >src/libmach/obj.c >diff -r 65fb8bb56c59 src/libmach/obj.c >--- a/src/libmach/obj.c Thu Apr 23 11:11:38 2015 +0100 >+++ b/src/libmach/obj.c Fri Nov 27 22:44:29 2015 +0530 >@@ -24,14 +24,14 @@ > int _is5(char*), > _is6(char*), > _is8(char*), >- _is9(char*), >+ /* _is9(char*), */ > _isk(char*), > _isq(char*), > _isv(char*), > _read5(Biobuf*, Prog*), > _read6(Biobuf*, Prog*), > _read8(Biobuf*, Prog*), >- _read9(Biobuf*, Prog*), >+ /* _read9(Biobuf*, Prog*), */ > _readk(Biobuf*, Prog*), > _readq(Biobuf*, Prog*), > _readv(Biobuf*, Prog*); >@@ -63,7 +63,7 @@ > /*[ObjSparc64]*/ {0, 0,}, > /*[ObjAmd64]*/ "amd64 .6", _is6, _read6, > /*[ObjSpim]*/ {0, 0,}, >- /*[ObjPower64]*/ "power64 .9", _is9, _read9, >+ /*[ObjPower64]*/ /* "power64 .9", _is9, _read9, >*/ > /*[Maxobjtype]*/ 0, 0 > }; > >That took compilation further but now it breaks at point 4 in your >issue. I hope I won't encounter more new issues :-). > Ah, yes, I completely forgot about that part. :/ Good luck with the rest of the compilation! You'll need it! >Cheers, -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-27 18:24 ` Ryan Gonzalez @ 2015-11-29 9:41 ` Vasudev Kamath 2015-11-29 14:38 ` Ryan Gonzalez 0 siblings, 1 reply; 45+ messages in thread From: Vasudev Kamath @ 2015-11-29 9:41 UTC (permalink / raw) To: Ryan Gonzalez; +Cc: Fans of the OS Plan 9 from Bell Labs Ryan Gonzalez <rymg19@gmail.com> writes: >>That took compilation further but now it breaks at point 4 in your >>issue. I hope I won't encounter more new issues :-). >> > > Ah, yes, I completely forgot about that part. :/ Good luck with the > rest of the compilation! You'll need it! Yes indeed. Now I'm having following error, after applying patch you mentioned in the comment. cc -m32 -o o.out y.tab.o lex.o /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libcc.a /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libbio.a /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/lib9.a (cd 6c; mk all) mk: no recipe to make 'div.o' So there is no div.c under src/cmd/6c. I see that old mkfile mkfile_o has div.c but I don't know where original source file went. Removing div.$O\ from mkfile gives the following error. cc -m32 -o o.out cgen.o enam.o list.o mul.o peep.o reg.o sgen.o swt.o txt.o pswt.o pgen.o /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libcc.a /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libbio.a /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/lib9.a cgen.o: In function `cgen': /home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:320: undefined reference to `sdiv2' /home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:323: undefined reference to `smod2' /home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:425: undefined reference to `sdivgen' /home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:427: undefined reference to `udivgen' /home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:632: undefined reference to `sdiv2' /home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:635: undefined reference to `smod2' /home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:759: undefined reference to `sdivgen' /home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:762: undefined reference to `udivgen' collect2: error: ld returned 1 exit status mk: cc -m32 ... : exit status=exit(1) mk: for j in ... : exit status=exit(1) mk: for j in ... : exit status=exit(1) In both case I'm hitting dead end. Any hints for going forward?. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-29 9:41 ` Vasudev Kamath @ 2015-11-29 14:38 ` Ryan Gonzalez 0 siblings, 0 replies; 45+ messages in thread From: Ryan Gonzalez @ 2015-11-29 14:38 UTC (permalink / raw) To: Vasudev Kamath; +Cc: Fans of the OS Plan 9 from Bell Labs On November 29, 2015 3:41:45 AM CST, Vasudev Kamath <vasudev@copyninja.info> wrote: >Ryan Gonzalez <rymg19@gmail.com> writes: > >>>That took compilation further but now it breaks at point 4 in your >>>issue. I hope I won't encounter more new issues :-). >>> >> >> Ah, yes, I completely forgot about that part. :/ Good luck with the >> rest of the compilation! You'll need it! > >Yes indeed. Now I'm having following error, after applying patch you >mentioned in the comment. > >cc -m32 -o o.out y.tab.o lex.o >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libcc.a >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libbio.a >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/lib9.a > >(cd 6c; mk all) >mk: no recipe to make 'div.o' > >So there is no div.c under src/cmd/6c. I see that old mkfile mkfile_o >has div.c but I don't know where original source file went. Removing >div.$O\ from mkfile gives the following error. > >cc -m32 -o o.out cgen.o enam.o list.o mul.o peep.o reg.o sgen.o swt.o >txt.o pswt.o pgen.o >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libcc.a >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/libbio.a >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/lib/lib9.a > >cgen.o: In function `cgen': >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:320: >undefined reference to `sdiv2' >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:323: >undefined reference to `smod2' >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:425: >undefined reference to `sdivgen' >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:427: >undefined reference to `udivgen' >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:632: >undefined reference to `sdiv2' >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:635: >undefined reference to `smod2' >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:759: >undefined reference to `sdivgen' >/home/vasudev/Documents/C_programming/compilers/9-cc/src/cmd/6c/cgen.c:762: >undefined reference to `udivgen' >collect2: error: ld returned 1 exit status >mk: cc -m32 ... : exit status=exit(1) >mk: for j in ... : exit status=exit(1) >mk: for j in ... : exit status=exit(1) > >In both case I'm hitting dead end. Any hints for going forward?. Well, the 6* compilers don't work ATM anyway, so I think you can just comment out the relevant lines in src/cmd/mkfile. -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-25 17:15 ` Ryan Gonzalez 2015-11-25 17:24 ` Vasudev Kamath 2015-11-27 16:50 ` Vasudev Kamath @ 2015-11-27 18:11 ` trebol 2 siblings, 0 replies; 45+ messages in thread From: trebol @ 2015-11-27 18:11 UTC (permalink / raw) To: 9fans Ryan Gonzalez <rymg19@gmail.com> wrote: > See > https://bitbucket.org/plan9-from-bell-labs/9-cc/issues/1/problems-building-under-x64-linux > for some tips on fixing various errors you may encounter, including this > one. (I opened that issue like 8 months ago...) > > On Wed, Nov 25, 2015 at 11:10 AM, Vasudev Kamath <vasudev@copyninja.info> > wrote: > > > > > Hi, > > > > I'm trying to compile ken-cc from ¹. Its giving me following error > > > > cc -c -m32 -g -O > > -I/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include > > -I/home/vasudev/Documents/C_programming/compilers/9-cc/include -DLINUX_386 > > -I../cmd/ 9obj.c > > In file included from > > /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0, > > from 9obj.c:5: > > /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and > > _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] > > # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use > > _DEFAULT_SOURCE" > > ^ > > 9obj.c:8:22: fatal error: 9c/9.out.h: No such file or directory > > compilation terminated. > > mk: cc -c -m32 ... : exit status=exit(1) > > mk: for j in ... : exit status=exit(1) > > > > I can't find 9c under src/cmd folder. Any hints on how to get it > > compiled?. > > > > Cheers, > > > > ¹ https://bitbucket.org/plan9-from-bell-labs/9-cc/overview > > > > > > > -- > Ryan > [ERROR]: Your autotools build scripts are 200 lines longer than your > program. Something’s wrong. > http://kirbyfan64.github.io/ h+ h+ ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-25 17:10 [9fans] Compiling ken-cc on Linux Vasudev Kamath 2015-11-25 17:15 ` Ryan Gonzalez @ 2015-11-26 12:10 ` Charles Forsyth 2015-11-26 12:18 ` David du Colombier 2015-11-26 18:15 ` Ryan Gonzalez 1 sibling, 2 replies; 45+ messages in thread From: Charles Forsyth @ 2015-11-26 12:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 603 bytes --] On 25 November 2015 at 17:10, Vasudev Kamath <vasudev@copyninja.info> wrote: > In file included from > /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0, > from 9obj.c:5: > /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and > _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] > # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use > _DEFAULT_SOURCE" > Of course, that particular one is just the latest crud from the constantly mutating gcc/clang environments. Why "DEFAULT" if it's not in fact the default? [-- Attachment #2: Type: text/html, Size: 1019 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 12:10 ` Charles Forsyth @ 2015-11-26 12:18 ` David du Colombier 2015-11-26 18:15 ` Ryan Gonzalez 1 sibling, 0 replies; 45+ messages in thread From: David du Colombier @ 2015-11-26 12:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs >> In file included from >> /home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0, >> from 9obj.c:5: >> /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and >> _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] >> # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use >> _DEFAULT_SOURCE" > > > Of course, that particular one is just the latest crud from the constantly > mutating gcc/clang environments. > Why "DEFAULT" if it's not in fact the default? Yes, that's a recent change. And since you want backward compatibility, you now have to define both _BSD_SOURCE/_SVID_SOURCE and _DEFAULT_SOURCE. -- David du Colombier ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 12:10 ` Charles Forsyth 2015-11-26 12:18 ` David du Colombier @ 2015-11-26 18:15 ` Ryan Gonzalez 2015-11-26 21:31 ` Charles Forsyth 2015-11-26 21:40 ` Andrew Simmons 1 sibling, 2 replies; 45+ messages in thread From: Ryan Gonzalez @ 2015-11-26 18:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs, Charles Forsyth On November 26, 2015 6:10:43 AM CST, Charles Forsyth <charles.forsyth@gmail.com> wrote: >On 25 November 2015 at 17:10, Vasudev Kamath <vasudev@copyninja.info> >wrote: > >> In file included from >> >/home/vasudev/Documents/C_programming/compilers/9-cc/Linux/386/include/lib9.h:9:0, >> from 9obj.c:5: >> /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and >> _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] >> # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use >> _DEFAULT_SOURCE" >> > >Of course, that particular one is just the latest crud from the >constantly >mutating gcc/clang environments. >Why "DEFAULT" if it's not in fact the default? That's actually mostly glibc, the only library on earth that makes me want to bang my head on the floor. I don't remember what GNU extension it is where glibc declares a function that Posix says should return no value as returning a value. So, when you use it like you're supposed to, you get errors. Then there's also crap like https://github.com/kirbyfan64/qlibc/commit/fb550e9f35a20492bcb6a767e9e3d33e30c00c59. It was a PR I opened. strptime was undefined. Depending on the system, you need to define one of: - _USE_XOPEN - _XOPEN_SOURCE - _BSD_SOURCE and now: - _DEFAULT_SOURCE -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 18:15 ` Ryan Gonzalez @ 2015-11-26 21:31 ` Charles Forsyth 2015-11-26 21:49 ` Ryan Gonzalez 2015-11-27 12:32 ` lucio 2015-11-26 21:40 ` Andrew Simmons 1 sibling, 2 replies; 45+ messages in thread From: Charles Forsyth @ 2015-11-26 21:31 UTC (permalink / raw) To: Ryan Gonzalez; +Cc: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 355 bytes --] On 26 November 2015 at 18:15, Ryan Gonzalez <rymg19@gmail.com> wrote: > the only library on earth that makes me want to bang my head on the floor. There must be others, surely. What about graphics libraries with APIs designed for FORTRAN (no data structures)? What about ostensible crypto libraries that get their random numbers from Walmart? [-- Attachment #2: Type: text/html, Size: 664 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 21:31 ` Charles Forsyth @ 2015-11-26 21:49 ` Ryan Gonzalez 2015-11-26 21:51 ` Charles Forsyth 2015-11-27 12:32 ` lucio 1 sibling, 1 reply; 45+ messages in thread From: Ryan Gonzalez @ 2015-11-26 21:49 UTC (permalink / raw) To: Charles Forsyth; +Cc: Fans of the OS Plan 9 from Bell Labs On November 26, 2015 3:31:11 PM CST, Charles Forsyth <charles.forsyth@gmail.com> wrote: >On 26 November 2015 at 18:15, Ryan Gonzalez <rymg19@gmail.com> wrote: > >> the only library on earth that makes me want to bang my head on the >floor. > > >There must be others, surely. What about graphics libraries with APIs >designed for FORTRAN (no data structures)? >What about ostensible crypto libraries that get their random numbers >from >Walmart? All that is bad...but glibc is worse. The issue is that you kinda *have* to use it, no matter how simple or complicated or stupid your program is. It's just...there. If you want to use a sane(r) libc like musl, your users need another dependency. Granted, there are other bad libraries or libraries with bad APIs (OpenSSL, SDL [especially for playing short sounds!], PCRE, etc.). However, you really don't *have* to use them. You can usually use RE2 or libregexp9 over PCRE, SFML over SDL, and so forth. NOT WITH GLIBC!! *rant over now* -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 21:49 ` Ryan Gonzalez @ 2015-11-26 21:51 ` Charles Forsyth 2015-11-26 21:56 ` Charles Forsyth 0 siblings, 1 reply; 45+ messages in thread From: Charles Forsyth @ 2015-11-26 21:51 UTC (permalink / raw) To: Ryan Gonzalez; +Cc: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 185 bytes --] On 26 November 2015 at 21:49, Ryan Gonzalez <rymg19@gmail.com> wrote: > All that is bad...but glibc is worse. The issue is that you kinda *have* > to use it, true, very true. [-- Attachment #2: Type: text/html, Size: 463 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 21:51 ` Charles Forsyth @ 2015-11-26 21:56 ` Charles Forsyth 2015-11-26 22:02 ` Ryan Gonzalez 0 siblings, 1 reply; 45+ messages in thread From: Charles Forsyth @ 2015-11-26 21:56 UTC (permalink / raw) To: Ryan Gonzalez; +Cc: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 666 bytes --] On 26 November 2015 at 21:51, Charles Forsyth <charles.forsyth@gmail.com> wrote: > On 26 November 2015 at 21:49, Ryan Gonzalez <rymg19@gmail.com> wrote: > >> All that is bad...but glibc is worse. The issue is that you kinda *have* >> to use it, > > > true, very true. i remember glibc being my first instance of having to buy a bigger drive just to build the thing. with clang+llvm, I revisited that, and also had to buy more RAM and CPU. i wondered whether to have a cron entry to speak "WTF?" into /dev/audio every so often, to save my voice (cron would be good because it could switch to "blistering barnacles!" when children were present). [-- Attachment #2: Type: text/html, Size: 1296 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 21:56 ` Charles Forsyth @ 2015-11-26 22:02 ` Ryan Gonzalez 2015-11-26 22:08 ` Charles Forsyth 0 siblings, 1 reply; 45+ messages in thread From: Ryan Gonzalez @ 2015-11-26 22:02 UTC (permalink / raw) To: Charles Forsyth; +Cc: Fans of the OS Plan 9 from Bell Labs On November 26, 2015 3:56:44 PM CST, Charles Forsyth <charles.forsyth@gmail.com> wrote: >On 26 November 2015 at 21:51, Charles Forsyth ><charles.forsyth@gmail.com> >wrote: > >> On 26 November 2015 at 21:49, Ryan Gonzalez <rymg19@gmail.com> wrote: >> >>> All that is bad...but glibc is worse. The issue is that you kinda >*have* >>> to use it, >> >> >> true, very true. > > >i remember glibc being my first instance of having to buy a bigger >drive >just to build the thing. >with clang+llvm, I revisited that, and also had to buy more RAM and >CPU. I remember the time I was trying to build LLVM+Clang on Windows in debug mode. Because...MinGW...I actually surpassed the file size limit when linking Clang, so I had to rebuild EVERYTHING. Stupid thing took about an hour each time. Because MinGW. >i wondered whether to have a cron entry to speak "WTF?" into /dev/audio >every so often, to save my voice >(cron would be good because it could switch to "blistering barnacles!" >when >children were present). It would be so funny if it malfunctioned: WTF barnacles! blistering WTF? -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 22:02 ` Ryan Gonzalez @ 2015-11-26 22:08 ` Charles Forsyth 2015-11-26 22:30 ` David du Colombier 0 siblings, 1 reply; 45+ messages in thread From: Charles Forsyth @ 2015-11-26 22:08 UTC (permalink / raw) To: Ryan Gonzalez; +Cc: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 573 bytes --] On 26 November 2015 at 22:02, Ryan Gonzalez <rymg19@gmail.com> wrote: > I remember the time I was trying to build LLVM+Clang on Windows in debug > mode. Because...MinGW...I actually surpassed the file size limit when > linking Clang, so I had to rebuild EVERYTHING. Stupid thing took about an > hour each time. Ah. Debug mode. It took me a while to suspect: I don't think you can build debug mode at all now in 32-bit mode. Even with gold instead of gnu ld it needs more memory than they can represent in their arrangement of 32-bit user-mode address space. [-- Attachment #2: Type: text/html, Size: 876 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 22:08 ` Charles Forsyth @ 2015-11-26 22:30 ` David du Colombier 2015-11-26 23:08 ` Ryan Gonzalez 0 siblings, 1 reply; 45+ messages in thread From: David du Colombier @ 2015-11-26 22:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs >> I remember the time I was trying to build LLVM+Clang on Windows in debug >> mode. Because...MinGW...I actually surpassed the file size limit when >> linking Clang, so I had to rebuild EVERYTHING. Stupid thing took about an >> hour each time. > > > Ah. Debug mode. It took me a while to suspect: I don't think you can build > debug mode at all now in 32-bit mode. > Even with gold instead of gnu ld it needs more memory than they can > represent in their arrangement of 32-bit user-mode address space. If I remember correctly, the last time I built clang in debug mode, it used more than 12 GB of memory during the linking. So yes, three times bigger than the 32-bit address space. -- David du Colombier ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 22:30 ` David du Colombier @ 2015-11-26 23:08 ` Ryan Gonzalez 2015-11-26 23:21 ` Charles Forsyth 0 siblings, 1 reply; 45+ messages in thread From: Ryan Gonzalez @ 2015-11-26 23:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs, David du Colombier On November 26, 2015 4:30:32 PM CST, David du Colombier <0intro@gmail.com> wrote: >>> I remember the time I was trying to build LLVM+Clang on Windows in >debug >>> mode. Because...MinGW...I actually surpassed the file size limit >when >>> linking Clang, so I had to rebuild EVERYTHING. Stupid thing took >about an >>> hour each time. >> >> >> Ah. Debug mode. It took me a while to suspect: I don't think you can >build >> debug mode at all now in 32-bit mode. >> Even with gold instead of gnu ld it needs more memory than they can >> represent in their arrangement of 32-bit user-mode address space. > >If I remember correctly, the last time I built clang in debug mode, it >used >more than 12 GB of memory during the linking. So yes, three times >bigger than the 32-bit address space. Holy crap, that's crazy. I built it in debug mode on Linux, but I don't think it used that much. I only have 6 GB right now! -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 23:08 ` Ryan Gonzalez @ 2015-11-26 23:21 ` Charles Forsyth 2015-11-26 23:41 ` Ryan Gonzalez ` (3 more replies) 0 siblings, 4 replies; 45+ messages in thread From: Charles Forsyth @ 2015-11-26 23:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 573 bytes --] On 26 November 2015 at 23:08, Ryan Gonzalez <rymg19@gmail.com> wrote: > Holy crap, that's crazy. I built it in debug mode on Linux, but I don't > think it used that much. I only have 6 GB right now! You have to remember that a C compiler is one of the largest, most complex software components that human beings have ever had to produce. The original C reference manual made it look deceptively easy, but really there's a ton of stuff going on in there, as you can see. How they ever got it going on a system with 64Kbytes of address space, I'll never know. [-- Attachment #2: Type: text/html, Size: 922 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 23:21 ` Charles Forsyth @ 2015-11-26 23:41 ` Ryan Gonzalez 2015-11-27 0:02 ` Brantley Coile ` (2 subsequent siblings) 3 siblings, 0 replies; 45+ messages in thread From: Ryan Gonzalez @ 2015-11-26 23:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs, Charles Forsyth On November 26, 2015 5:21:54 PM CST, Charles Forsyth <charles.forsyth@gmail.com> wrote: >On 26 November 2015 at 23:08, Ryan Gonzalez <rymg19@gmail.com> wrote: > >> Holy crap, that's crazy. I built it in debug mode on Linux, but I >don't >> think it used that much. I only have 6 GB right now! > > >You have to remember that a C compiler is one of the largest, most >complex >software components that human beings have ever had to produce. >The original C reference manual made it look deceptively easy, but >really >there's a ton of stuff going on in there, as you can see. >How they ever got it going on a system with 64Kbytes of address space, >I'll >never know. I read in LBAC that one compiler had about 80 passes. All of which stored their results on disk. I can't help but shudder at the thought of how long those things took to compile... -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 23:21 ` Charles Forsyth 2015-11-26 23:41 ` Ryan Gonzalez @ 2015-11-27 0:02 ` Brantley Coile 2015-11-27 8:13 ` Giacomo Tesio 2015-11-27 12:05 ` Steffen Nurpmeso 3 siblings, 0 replies; 45+ messages in thread From: Brantley Coile @ 2015-11-27 0:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1225 bytes --] Clearly history is wrong. It would never be able to compile C in less than 18MB (1/2 of clang’s text size). Therefor Unix didn’t really happen. It’s all been a phone company conspiracy for world domination, like the NASA not really putting a man on the moon. We were just *told* they had built a system in 1973 using a simple two pass compiler that would fit into about 28KW of memory. AT&T would have gotten away with it too, if it weren’t for their great mistake—the 3B20. Results: no more “One system; it works." > On Nov 26, 2015, at 6:21 PM, Charles Forsyth <charles.forsyth@gmail.com> wrote: > > > On 26 November 2015 at 23:08, Ryan Gonzalez <rymg19@gmail.com <mailto:rymg19@gmail.com>> wrote: > Holy crap, that's crazy. I built it in debug mode on Linux, but I don't think it used that much. I only have 6 GB right now! > > You have to remember that a C compiler is one of the largest, most complex software components that human beings have ever had to produce. > The original C reference manual made it look deceptively easy, but really there's a ton of stuff going on in there, as you can see. > How they ever got it going on a system with 64Kbytes of address space, I'll never know. [-- Attachment #2: Type: text/html, Size: 2055 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 23:21 ` Charles Forsyth 2015-11-26 23:41 ` Ryan Gonzalez 2015-11-27 0:02 ` Brantley Coile @ 2015-11-27 8:13 ` Giacomo Tesio 2015-11-27 8:56 ` arnold 2015-11-27 12:42 ` tlaronde 2015-11-27 12:05 ` Steffen Nurpmeso 3 siblings, 2 replies; 45+ messages in thread From: Giacomo Tesio @ 2015-11-27 8:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1207 bytes --] 2015-11-27 0:21 GMT+01:00 Charles Forsyth <charles.forsyth@gmail.com>: > > On 26 November 2015 at 23:08, Ryan Gonzalez <rymg19@gmail.com> wrote: > >> Holy crap, that's crazy. I built it in debug mode on Linux, but I don't >> think it used that much. I only have 6 GB right now! > > > You have to remember that a C compiler is one of the largest, most complex > software components that human beings have ever had to produce. > The original C reference manual made it look deceptively easy, but really > there's a ton of stuff going on in there, as you can see. > How they ever got it going on a system with 64Kbytes of address space, > I'll never know. > I'd love to read more about this, Charles. :-) I know nothing about compilers, but actually gcc and clang dimension and complexity is astonishing. I've always thought that this is due to their desire to compile many different language optimized for many different OS and architectures on many different OS and architecture. Alternative compilers, like tcc, only build C on very few architectures / os with almost no optimization: they are much smaller, but still not standard compliant. How can it be? Giacomo [-- Attachment #2: Type: text/html, Size: 2111 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-27 8:13 ` Giacomo Tesio @ 2015-11-27 8:56 ` arnold 2015-11-27 13:33 ` Steffen Nurpmeso 2015-11-27 12:42 ` tlaronde 1 sibling, 1 reply; 45+ messages in thread From: arnold @ 2015-11-27 8:56 UTC (permalink / raw) To: 9fans > I know nothing about compilers, but actually gcc and clang dimension and > complexity is astonishing. > I've always thought that this is due to their desire to compile many > different language optimized for many different OS and architectures on > many different OS and architecture. That is a very large part of the reason. People also have used GCC (and I guess clang/llvm) as research vehicles, and such bits and pieces get included even if not stricly necessary. Also note that C++ is a hugely complicated langauge, and getting all the standards stuff right for it (and even for C) takes a lot of work. But you summed it up: * Multiple languages (front ends) * Multiple architectures (code generators / backends) * Optimized - a huge part of GCC is different kinds of optimizers > Alternative compilers, like tcc, only build C on very few architectures / > os with almost no optimization: they are much smaller, but still not > standard compliant. > > How can it be? In the case of TCC, there is no real guiding hand. People do what they feel like, or as they need it. Also, the original code base leaves a lot to be desired from a software design / engineering standpoint. (Function names consisting of a single letter!) TCC compiles really fast, and it's (finally) good enough that I can use it for my personal development / testing, but I would not use it to build a production binary, the code quality is much poorer. On Linux you can't use it for debugging either - it doesn't generate the debug info you need. :-( For that, GCC and clang are the way to go. I agree with the general sentiments - GLIBC and GCC are both bloated. But for the day-to-day work that *I* do, they're livable. My two cents, Arnold ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-27 8:56 ` arnold @ 2015-11-27 13:33 ` Steffen Nurpmeso 2015-11-28 0:55 ` erik quanstrom 0 siblings, 1 reply; 45+ messages in thread From: Steffen Nurpmeso @ 2015-11-27 13:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs arnold@skeeve.com wrote: |> Alternative compilers, like tcc, only build C on very few architectures / |> os with almost no optimization: they are much smaller, but still not |> standard compliant. |TCC compiles really fast, and it's (finally) good enough that I can use |it for my personal development / testing, but I would not use it to |build a production binary, the code quality is much poorer. On Linux |you can't use it for debugging either - it doesn't generate the |debug info you need. :-( For that, GCC and clang are the way to go. I just started to use tcc(1) for faster recompilations during my chaotic way of walking, and it was an a-ha just as was the detection of jikes(1) compared to the Java-shipped compiler in, say, 1999. (And in fact that was the reason to start learning C++, later C, and not continue with only Perl and Java.) ?2[sdaoden@wales ]$ time make CC=clang devel >/dev/null 2>&1 0m55.37s real 0m29.44s user 0m27.24s system ?0[sdaoden@wales ]$ time make CC=gcc devel >/dev/null 2>&1 0m50.04s real 0m26.13s user 0m24.92s system ?2[sdaoden@wales ]$ time make CC=tcc devel >/dev/null 2>&1 0m17.90s real 0m7.29s user 0m12.07s system But without reconfiguration in normal development it feels more drastic than these lines suggest. Of course, ship-out user code. Plan9 users don't have those problems in their native self-contained environment, also the UnixWare and native Sun cc's are ok, but on *BSD and Linux you really don't have any more options. E.g., i just tried pcc(1), which could be one, on a Linux box: Using C compiler $CC="pcc" /usr/include/stdc-predef.h:59: warning: __STDC_ISO_10646__ redefined (previously defined at "./___tmp12443.c" line -9) ld: cannot find crtbegin.o: No such file or directory well we could but.. ld: cannot find -lpcc there is none! error: ld terminated with status 1 ERROR: i cannot compile a "Hello world" via pcc -I/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include/ -I/home/sdaoden/usr/include -I/usr/local/include -I/usr/include -L/home/sdaoden/usr/lib -L/lib -L/usr/local/lib -L/usr/lib That after some work already. VoidLinux has a package, though, i should try that. |I agree with the general sentiments - GLIBC and GCC are both bloated. |But for the day-to-day work that *I* do, they're livable. Due to the large community and the commercial interest (remember the billion dollar campaign of IBM over a decade ago) you have the newest technologies in a usable state. I.e., i've found a drastic memory bug in Jörg Schilling's Bourne shell (likely developed only on Solaris rooted) simply by compiling and starting it under FreeBSD. And i have found stack read violations simply by running them under Linux? I always had my own memory allocation stuff with tracing and logging and canaries, but read violations are hard to detect without real red zones. And it's easy to simply look into /proc/PID/ and see a lot of things at a glance via ls(1) / cat(1) that otherwise require special programs or things which are real horror for me, like dtrace (no!). Acid has it at least in its name. Never liked debug robots anyway. But otherwise i always like going back to BSD, i guess just Plan9 people like to come back into the grown rather self-contained environment. You install the ISO and are ready to go, with network and development. I.e., i install a new FreeBSD and the configuration files from 2002 still work. That is valuable. I think there is pcc for NetBSD, also. --steffen ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-27 13:33 ` Steffen Nurpmeso @ 2015-11-28 0:55 ` erik quanstrom 2015-11-30 15:46 ` Steffen Nurpmeso 0 siblings, 1 reply; 45+ messages in thread From: erik quanstrom @ 2015-11-28 0:55 UTC (permalink / raw) To: 9fans > memory bug in Jörg Schilling's Bourne shell (likely developed only > on Solaris rooted) simply by compiling and starting it under > FreeBSD. And i have found stack read violations simply by running given cdrtools, this is not a surprise. https://en.wikipedia.org/wiki/Cdrtools#Device_naming "all the world's a vax^h^h^hscsi" - erik ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-28 0:55 ` erik quanstrom @ 2015-11-30 15:46 ` Steffen Nurpmeso 0 siblings, 0 replies; 45+ messages in thread From: Steffen Nurpmeso @ 2015-11-30 15:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs erik quanstrom <quanstro@quanstro.net> wrote: |> memory bug in Jörg Schilling's Bourne shell (likely developed only |> on Solaris rooted) simply by compiling and starting it under |> FreeBSD. And i have found stack read violations simply by running | |given cdrtools, this is not a surprise. | https://en.wikipedia.org/wiki/Cdrtools#Device_naming |"all the world's a vax^h^h^hscsi" ..hm, i have read his dissertation some years ago, from the end of the 80s?, in which he translates the SunOS operating system manual to German for almost a hundred pages? --steffen ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-27 8:13 ` Giacomo Tesio 2015-11-27 8:56 ` arnold @ 2015-11-27 12:42 ` tlaronde 2015-11-27 14:07 ` Giacomo Tesio 1 sibling, 1 reply; 45+ messages in thread From: tlaronde @ 2015-11-27 12:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Nov 27, 2015 at 09:13:20AM +0100, Giacomo Tesio wrote: > > I know nothing about compilers, but actually gcc and clang dimension and > complexity is astonishing. It's not astonishing: it's research. They want to prove that a black hole does exist. So they write a "model", a software implementation of black holes that is, indeed, able to absorb every bit of RAM, every block of disk, every CPU cycle so that whatever is put in a computer, nothing can ever go out. And the thing finally collapses due to its very size: so big that no one is able to understand and correct it. Then it is called: "standard", a de facto no varietur, not because it is perfect not to mention useful, but because it is impossible to evolve. It's a kind of success (though there are a lot of competing implementations of software black holes, improving almost endlessly: less and less signal, more and more noise). -- Thierry Laronde <tlaronde +AT+ polynum +dot+ com> http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-27 12:42 ` tlaronde @ 2015-11-27 14:07 ` Giacomo Tesio 2015-11-27 14:34 ` tlaronde 2015-11-28 1:01 ` erik quanstrom 0 siblings, 2 replies; 45+ messages in thread From: Giacomo Tesio @ 2015-11-27 14:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 805 bytes --] 2015-11-27 13:42 GMT+01:00 <tlaronde@polynum.com>: > On Fri, Nov 27, 2015 at 09:13:20AM +0100, Giacomo Tesio wrote: > > > > I know nothing about compilers, but actually gcc and clang dimension and > > complexity is astonishing. > > It's not astonishing: it's research. They want to prove that a black > hole does exist. > 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. Giacomo [-- Attachment #2: Type: text/html, Size: 1246 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-27 14:07 ` Giacomo Tesio @ 2015-11-27 14:34 ` tlaronde 2015-11-28 1:01 ` erik quanstrom 1 sibling, 0 replies; 45+ messages in thread From: tlaronde @ 2015-11-27 14:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Nov 27, 2015 at 03:07:30PM +0100, Giacomo Tesio 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. I guess it depends on what is the "standard". The naked C language is (was) simple. The guaranteed routines were something else: the C library---contrary to Pascal, for example, where some routines were part of the language. That's the way I understand Charles' irony: it seems difficult to find a more simple (and efficient) language as C. There are problem with standards but there are far more problems with people that do not refer to standards and do not know what they use. Using Plan9' APE is a good way, for example, to ensure that one is only using POSIX. Yes, it is not up-to-date since POSIX evolves; but failing to compile with APE is generally not due to missing pieces in APE but to fuzzy use of things outside POSIX in the program one wants to compile. BTW this was already the case when the Plan9 paper about APE was written. But it's getting worse. -- Thierry Laronde <tlaronde +AT+ polynum +dot+ com> http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-27 14:07 ` Giacomo Tesio 2015-11-27 14:34 ` tlaronde @ 2015-11-28 1:01 ` erik quanstrom 1 sibling, 0 replies; 45+ messages in thread From: erik quanstrom @ 2015-11-28 1:01 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 23:21 ` Charles Forsyth ` (2 preceding siblings ...) 2015-11-27 8:13 ` Giacomo Tesio @ 2015-11-27 12:05 ` Steffen Nurpmeso 3 siblings, 0 replies; 45+ messages in thread From: Steffen Nurpmeso @ 2015-11-27 12:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs |How they ever got it going on a system with 64Kbytes of address space\ |, I'll never know. Yeah! --steffen ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 21:31 ` Charles Forsyth 2015-11-26 21:49 ` Ryan Gonzalez @ 2015-11-27 12:32 ` lucio 1 sibling, 0 replies; 45+ messages in thread From: lucio @ 2015-11-27 12:32 UTC (permalink / raw) To: 9fans > What about ostensible crypto libraries that get their random numbers from > Walmart? Do they get those over the counter? Lucio. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-26 18:15 ` Ryan Gonzalez 2015-11-26 21:31 ` Charles Forsyth @ 2015-11-26 21:40 ` Andrew Simmons 1 sibling, 0 replies; 45+ messages in thread From: Andrew Simmons @ 2015-11-26 21:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > the only library on earth that makes me want to bang my head on the floor. > You need to get out more ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux
@ 2015-11-28 6:42 da Tyga
2015-11-28 7:40 ` Brantley Coile
2015-11-28 20:13 ` Ryan Gonzalez
0 siblings, 2 replies; 45+ messages in thread
From: da Tyga @ 2015-11-28 6:42 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]
I have been following this discussion about the C compiler and can no
longer stop myself from making a (snarky?) comment.
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. 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.
On 28 November 2015 at 12:01, erik quanstrom <quanstro@quanstro.net> 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
>
>
[-- Attachment #2: Type: text/html, Size: 2967 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-28 6:42 da Tyga @ 2015-11-28 7:40 ` Brantley Coile 2015-11-28 20:31 ` Anthony Sorace 2015-11-28 20:13 ` Ryan Gonzalez 1 sibling, 1 reply; 45+ messages in thread From: Brantley Coile @ 2015-11-28 7:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Great point. And you actually don’t 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’m 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’s 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’s 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’t 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. Brantley > On Nov 28, 2015, at 1:42 AM, da Tyga <cyberfonic@gmail.com> wrote: > > I have been following this discussion about the C compiler and can no longer stop myself from making a (snarky?) comment. > > 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. 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. > > > On 28 November 2015 at 12:01, erik quanstrom <quanstro@quanstro.net> 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 > > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-28 7:40 ` Brantley Coile @ 2015-11-28 20:31 ` Anthony Sorace 2015-11-28 23:33 ` Brantley Coile 0 siblings, 1 reply; 45+ messages in thread From: Anthony Sorace @ 2015-11-28 20:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Brantley wrote: > 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... Note the "almost all" in there. It's important not to get dogmatic about such things. The argument isn't that kencc is at precisely the perfect point on the simplicity-vs-optimization spectrum, but that it's pretty darn close, closer that known alternatives, and errs on the safer side. Likely there are optimizations or features in newer chipsets that would be worth supporting, but even so: we've got a long way to go before hitting gcc/clang levels. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-28 20:31 ` Anthony Sorace @ 2015-11-28 23:33 ` Brantley Coile 2015-11-29 6:12 ` lucio 0 siblings, 1 reply; 45+ messages in thread From: Brantley Coile @ 2015-11-28 23:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Not dogmatic. Just 38 years and I still believe small is beautify. One interesting thing is that for the past twenty years new architectures have been designed to run C code well. Just check out the papers a ISCA. Then why do we have to have such complicated compilers to generate code for it. > On Nov 28, 2015, at 3:31 PM, Anthony Sorace <a@9srv.net> wrote: > > Brantley wrote: > >> 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... > > Note the "almost all" in there. It's important not to get dogmatic about such things. The argument isn't that kencc is at precisely the perfect point on the simplicity-vs-optimization spectrum, but that it's pretty darn close, closer that known alternatives, and errs on the safer side. Likely there are optimizations or features in newer chipsets that would be worth supporting, but even so: we've got a long way to go before hitting gcc/clang levels. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-28 23:33 ` Brantley Coile @ 2015-11-29 6:12 ` lucio 0 siblings, 0 replies; 45+ messages in thread From: lucio @ 2015-11-29 6:12 UTC (permalink / raw) To: 9fans > One interesting thing is that for the past twenty years new > architectures have been designed to run C code well. Just check out > the papers a ISCA. Then why do we have to have such complicated > compilers to generate code for it. I'm pretty sure that you can lay that at C's door. Had Algol or Pascal been targeted, the architectures would not have so many loopholes to go insane over. C's pragmatism came back to bite it. Of course, Algol or Pascal's discipline meant they never stood a chance, so it's a lose-lose situation. Let's be grateful that C existed at all. Had ADA or PL/I won that war, I doubt the Personal Computer would have ever become affordable. What it suggests to me is that the next programming notation should first of all describe an architecture that can be engineered without an infinite array of corner cutting features that can't be represented in any semblance of programming code, which is why the compiler needs to know about each and every one and even the likely circumstances under which they ought to be used. Then we can hand to the engineers a programming language they can target with their architectures and they won't botch it too badly. On further thought, it's obvious where it all went wrong: C is not one language, it is only scaffolding. Targeting it was bound to lead to an infinite number of outcomes. Lucio. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-28 6:42 da Tyga 2015-11-28 7:40 ` Brantley Coile @ 2015-11-28 20:13 ` Ryan Gonzalez 2015-11-29 5:57 ` lucio 1 sibling, 1 reply; 45+ messages in thread From: Ryan Gonzalez @ 2015-11-28 20:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs, da Tyga On November 28, 2015 12:42:25 AM CST, da Tyga <cyberfonic@gmail.com> wrote: >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 board 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. >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 compatibility 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 disappearing, just moving around? I prefer languages that prefer correctness to perfect, cross-platform APIs 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 <quanstro@quanstro.net> >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 >> >> -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity. CURRENTLY LISTENING TO: The Key We've Lost (Xenoblade Chronicles X) ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-28 20:13 ` Ryan Gonzalez @ 2015-11-29 5:57 ` lucio 2015-11-29 16:17 ` tlaronde 0 siblings, 1 reply; 45+ messages in thread From: lucio @ 2015-11-29 5:57 UTC (permalink / raw) To: 9fans > I think the issue is trying to fix a broken problem. Perfect > compatibility 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 disappearing, just moving around? Basically, increased CPU complexity provides increased performance, which is then used to provide features that only unskilled users could wish for. I once described the syndrome as "I can't figure how this application works, but the next release will be easier to use". I remember using AutoCad 2.6 on an 8086 with a floating point accelerator and being impressed by the speed of its 3D rendering. I have no idea how AutoCad behaves these days, but faster rendering would imply finishing before it even started. So where is the real improvement? Sadly, we developers buy all the hype just like uneducated users. Another example: I switched from XYWrite to Brief 1.something because the latter was as fast, but in addition it handled backspace in replace mode correctly (XYWrite pulled back the remainder of the line, where Brief actually replaced the precedingcharacter with a space and moved the cursor under it). Brief 2.1 was better, with worthwhile improvements, whereas 3.1 was a dog. I never promoted myself to it, No doubt, the developer had made enough money from users like me to afford a 386 PC and forgot that I would not have access to one :-( In summary, we have the resources, we may as well squander them. And those who can't afford them? "Let them eat cake!". Lucio. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [9fans] Compiling ken-cc on Linux 2015-11-29 5:57 ` lucio @ 2015-11-29 16:17 ` tlaronde 0 siblings, 0 replies; 45+ messages in thread From: tlaronde @ 2015-11-29 16:17 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sun, Nov 29, 2015 at 07:57:58AM +0200, lucio@proxima.alt.za wrote: > > I remember using AutoCad 2.6 on an 8086 with a floating point > accelerator and being impressed by the speed of its 3D rendering. I > have no idea how AutoCad behaves these days, but faster rendering > would imply finishing before it even started. So where is the real > improvement? > You could have been impressed with Microstation (originally from InterGraph) doing everything in scaled integers (it was clear it came from Unix world too by several features, like regexp) so using only the CPU. It run smoothly on 386 with DOS and DOS extender. Once they "ported" it to Windows 95 and NT, we waited years for the hardware to be able to give back the performance we had with "poorer" hardware and OS. It almost took 10 years if I'm not mistaken... And I hear that progress is "continuous". In another world probably... -- Thierry Laronde <tlaronde +AT+ polynum +dot+ com> http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2015-11-30 15:46 UTC | newest] Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-11-25 17:10 [9fans] Compiling ken-cc on Linux Vasudev Kamath 2015-11-25 17:15 ` Ryan Gonzalez 2015-11-25 17:24 ` Vasudev Kamath 2015-11-26 12:08 ` Charles Forsyth 2015-11-27 16:50 ` Vasudev Kamath 2015-11-27 16:59 ` Ryan Gonzalez 2015-11-27 17:16 ` Vasudev Kamath 2015-11-27 18:24 ` Ryan Gonzalez 2015-11-29 9:41 ` Vasudev Kamath 2015-11-29 14:38 ` Ryan Gonzalez 2015-11-27 18:11 ` trebol 2015-11-26 12:10 ` Charles Forsyth 2015-11-26 12:18 ` David du Colombier 2015-11-26 18:15 ` Ryan Gonzalez 2015-11-26 21:31 ` Charles Forsyth 2015-11-26 21:49 ` Ryan Gonzalez 2015-11-26 21:51 ` Charles Forsyth 2015-11-26 21:56 ` Charles Forsyth 2015-11-26 22:02 ` Ryan Gonzalez 2015-11-26 22:08 ` Charles Forsyth 2015-11-26 22:30 ` David du Colombier 2015-11-26 23:08 ` Ryan Gonzalez 2015-11-26 23:21 ` Charles Forsyth 2015-11-26 23:41 ` Ryan Gonzalez 2015-11-27 0:02 ` Brantley Coile 2015-11-27 8:13 ` Giacomo Tesio 2015-11-27 8:56 ` arnold 2015-11-27 13:33 ` Steffen Nurpmeso 2015-11-28 0:55 ` erik quanstrom 2015-11-30 15:46 ` Steffen Nurpmeso 2015-11-27 12:42 ` tlaronde 2015-11-27 14:07 ` Giacomo Tesio 2015-11-27 14:34 ` tlaronde 2015-11-28 1:01 ` erik quanstrom 2015-11-27 12:05 ` Steffen Nurpmeso 2015-11-27 12:32 ` lucio 2015-11-26 21:40 ` Andrew Simmons 2015-11-28 6:42 da Tyga 2015-11-28 7:40 ` Brantley Coile 2015-11-28 20:31 ` Anthony Sorace 2015-11-28 23:33 ` Brantley Coile 2015-11-29 6:12 ` lucio 2015-11-28 20:13 ` Ryan Gonzalez 2015-11-29 5:57 ` lucio 2015-11-29 16:17 ` tlaronde
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).