Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #96066 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2016-11-08 03:07 -0800 |
| Last post | 2016-11-18 20:36 +0800 |
| Articles | 20 on this page of 80 — 18 participants |
Back to article view | Back to comp.lang.c
Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 03:07 -0800
Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-08 13:25 +0100
Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 05:47 -0800
Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-08 21:03 +0100
Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 12:10 -0800
Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-08 21:17 +0100
Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 13:27 -0800
Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-09 11:19 +0100
Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 03:00 -0800
Re: Experimental languages/features for C or similar supercat@casperkitty.com - 2016-11-09 09:04 -0800
Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-09 09:57 -0800
Re: Experimental languages/features for C or similar fir <profesor.fir@gmail.com> - 2016-11-08 05:16 -0800
Re: Experimental languages/features for C or similar supercat@casperkitty.com - 2016-11-08 06:22 -0800
Re: Experimental languages/features for C or similar fir <profesor.fir@gmail.com> - 2016-11-08 06:52 -0800
Re: Experimental languages/features for C or similar fir <profesor.fir@gmail.com> - 2016-11-08 07:08 -0800
Re: Experimental languages/features for C or similar supercat@casperkitty.com - 2016-11-08 07:47 -0800
Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 08:13 -0800
Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 08:48 -0800
Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-17 03:21 -0800
Re: Experimental languages/features for C or similar "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-08 22:16 +0800
Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 08:00 -0800
Re: Experimental languages/features for C or similar "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-09 00:13 +0800
Re: Experimental languages/features for C or similar supercat@casperkitty.com - 2016-11-08 08:41 -0800
Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-08 08:50 -0800
Re: Experimental languages/features for C or similar Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-08 17:10 +0000
Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-08 19:06 +0100
Re: Experimental languages/features for C or similar Andreas <nospam@invalid.invalid> - 2016-11-08 21:43 +0100
Re: Experimental languages/features for C or similar luser droog <luser.droog@gmail.com> - 2016-11-10 12:29 -0800
Re: Experimental languages/features for C or similar Thiago Adams <thiago.adams@gmail.com> - 2016-11-11 02:35 -0800
Re: Experimental languages/features for C or similar BartC <bc@freeuk.com> - 2016-11-11 10:43 +0000
Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-17 20:15 +0100
Re: Experimental languages/features for C or similar Keith Thompson <kst-u@mib.org> - 2016-11-17 11:59 -0800
Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-17 22:27 +0100
Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-17 22:45 +0100
Re: Experimental languages/features for C or similar Keith Thompson <kst-u@mib.org> - 2016-11-17 14:28 -0800
Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 00:13 +0100
Re: Experimental languages/features for C or similar Keith Thompson <kst-u@mib.org> - 2016-11-17 15:37 -0800
Re: Experimental languages/features for C or similar Gareth Owen <gwowen@gmail.com> - 2016-11-18 09:29 +0000
Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 21:59 +0100
Re: Experimental languages/features for C or similar Gareth Owen <gwowen@gmail.com> - 2016-11-18 21:14 +0000
Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 22:38 +0100
Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 11:26 +0100
Re: Experimental languages/features for C or similar Keith Thompson <kst-u@mib.org> - 2016-11-18 08:56 -0800
Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-18 08:16 +0100
Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 11:42 +0100
Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-18 13:16 +0100
Re: Experimental languages/features for C or similar Richard Heathfield <rjh@cpax.org.uk> - 2016-11-18 12:23 +0000
Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-18 14:28 +0100
Re: Experimental languages/features for C or similar Richard Heathfield <rjh@cpax.org.uk> - 2016-11-18 14:24 +0000
Re: Experimental languages/features for C or similar raltbos@xs4all.nl (Richard Bos) - 2016-11-18 14:34 +0000
Re: Experimental languages/features for C or similar BartC <bc@freeuk.com> - 2016-11-18 14:37 +0000
Re: Experimental languages/features for C or similar Gareth Owen <gwowen@gmail.com> - 2016-11-18 14:38 +0000
Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-18 15:47 +0100
[OT] Linux and Firefox "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 22:50 +0800
Re: Window$ and Firefox "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 22:51 +0800
Re: taskkill "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 22:52 +0800
Re: taskkill David Brown <david.brown@hesbynett.no> - 2016-11-18 16:44 +0100
Re: Experimental languages/features for C or similar Richard Heathfield <rjh@cpax.org.uk> - 2016-11-18 15:11 +0000
Re: Who cares (about Window$)? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 23:24 +0800
Re: Who cares (about Window$)? David Brown <david.brown@hesbynett.no> - 2016-11-18 16:41 +0100
Re: Who cares (about Window$)? Melzzzzz <mel@zzzzz.com> - 2016-11-18 16:45 +0100
Re: Who cares (about Window$)? David Brown <david.brown@hesbynett.no> - 2016-11-18 17:35 +0100
Re: Who cares (about Window$)? Real Troll <real.troll@trolls.com> - 2016-11-18 13:10 -0400
Re: Who cares (about Window$)? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-11-18 18:29 +0000
Re: Who cares (about Window$)? jameskuyper@verizon.net - 2016-11-18 11:49 -0800
Re: Experimental languages/features for C or similar jameskuyper@verizon.net - 2016-11-18 11:42 -0800
Re: Experimental languages/features for C or similar Richard Heathfield <rjh@cpax.org.uk> - 2016-11-19 20:37 +0000
Re: Experimental languages/features for C or similar Gareth Owen <gwowen@gmail.com> - 2016-11-18 12:34 +0000
Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 13:46 +0100
Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 13:44 +0100
Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-18 14:44 +0100
Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-19 01:16 +0100
Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-19 15:43 +0100
Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-19 18:13 +0100
Re: Experimental languages/features for C or similar Richard Heathfield <rjh@cpax.org.uk> - 2016-11-18 00:16 +0000
Re: Experimental languages/features for C or similar jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 09:25 +0100
Re: Experimental languages/features for C or similar BartC <bc@freeuk.com> - 2016-11-18 18:15 +0000
Re: Experimental languages/features for C or similar Gareth Owen <gwowen@gmail.com> - 2016-11-18 19:18 +0000
Re: Experimental languages/features for C or similar David Brown <david.brown@hesbynett.no> - 2016-11-18 08:20 +0100
Re: Experimental languages/features for C or similar "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 20:36 +0800
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-11-18 16:45 +0100 |
| Subject | Re: Who cares (about Window$)? |
| Message-ID | <20161118164531.543390f2@maxa-pc> |
| In reply to | #96848 |
On Fri, 18 Nov 2016 16:41:45 +0100 David Brown <david.brown@hesbynett.no> wrote: > On 18/11/16 16:24, Mr. Man-wai Chang wrote: > > On 18/11/2016 11:11 PM, Richard Heathfield wrote: > >>> I expect there is a way to do this on Windows too, but I don't > >>> know what it might be. > >> > >> <shrug> Who cares? :-) > > > > You masters don't use Window$? I am amazed! > > You masters don't play DirectX games? Most of them were written in > > C if not C++, I believe. > > > > We are not "masters". Most people in this group are people who > program in C, or used to program in C, or are otherwise interested in > C programming. If anyone thinks they have fully "mastered" C > programming, they are wrong - despite having perhaps 30+ years of > experience. Heh, I was hired in 1994 as C expert by American company ;) -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-18 17:35 +0100 |
| Subject | Re: Who cares (about Window$)? |
| Message-ID | <o0nak3$38q$2@dont-email.me> |
| In reply to | #96850 |
On 18/11/16 16:45, Melzzzzz wrote: > On Fri, 18 Nov 2016 16:41:45 +0100 > David Brown <david.brown@hesbynett.no> wrote: > >> On 18/11/16 16:24, Mr. Man-wai Chang wrote: >>> On 18/11/2016 11:11 PM, Richard Heathfield wrote: >>>>> I expect there is a way to do this on Windows too, but I don't >>>>> know what it might be. >>>> >>>> <shrug> Who cares? :-) >>> >>> You masters don't use Window$? I am amazed! >>> You masters don't play DirectX games? Most of them were written in >>> C if not C++, I believe. >>> >> >> We are not "masters". Most people in this group are people who >> program in C, or used to program in C, or are otherwise interested in >> C programming. If anyone thinks they have fully "mastered" C >> programming, they are wrong - despite having perhaps 30+ years of >> experience. > > Heh, I was hired in 1994 as C expert by American company ;) > Oh, there are plenty of people here who are /experts/ at C. But have you /mastered/ it?
[toc] | [prev] | [next] | [standalone]
| From | Real Troll <real.troll@trolls.com> |
|---|---|
| Date | 2016-11-18 13:10 -0400 |
| Subject | Re: Who cares (about Window$)? |
| Message-ID | <o0nc7m$11in$1@gioia.aioe.org> |
| In reply to | #96861 |
On 18/11/2016 16:35, David Brown wrote: > Oh, there are plenty of people here who are /experts/ at C. But have > you /mastered/ it? > I can write "Hello World!" program.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2016-11-18 18:29 +0000 |
| Subject | Re: Who cares (about Window$)? |
| Message-ID | <o0nhak$ic$1@news.albasani.net> |
| In reply to | #96861 |
On 2016-11-18, David Brown <david.brown@hesbynett.no> wrote: > On 18/11/16 16:45, Melzzzzz wrote: >> On Fri, 18 Nov 2016 16:41:45 +0100 >> David Brown <david.brown@hesbynett.no> wrote: >> >>> On 18/11/16 16:24, Mr. Man-wai Chang wrote: >>>> On 18/11/2016 11:11 PM, Richard Heathfield wrote: >>>>>> I expect there is a way to do this on Windows too, but I don't >>>>>> know what it might be. >>>>> >>>>> <shrug> Who cares? :-) >>>> >>>> You masters don't use Window$? I am amazed! >>>> You masters don't play DirectX games? Most of them were written in >>>> C if not C++, I believe. >>>> >>> >>> We are not "masters". Most people in this group are people who >>> program in C, or used to program in C, or are otherwise interested in >>> C programming. If anyone thinks they have fully "mastered" C >>> programming, they are wrong - despite having perhaps 30+ years of >>> experience. >> >> Heh, I was hired in 1994 as C expert by American company ;) >> > > Oh, there are plenty of people here who are /experts/ at C. But have > you /mastered/ it? > No. -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-11-18 11:49 -0800 |
| Subject | Re: Who cares (about Window$)? |
| Message-ID | <f005e16d-836d-4f29-8b6d-e28a093c22ca@googlegroups.com> |
| In reply to | #96843 |
On Friday, November 18, 2016 at 10:24:35 AM UTC-5, Mr. Man-wai Chang wrote: > On 18/11/2016 11:11 PM, Richard Heathfield wrote: > >> I expect there is a way to do this on Windows too, but I don't know what > >> it might be. > > > > <shrug> Who cares? :-) > > You masters don't use Window$? I am amazed! I don't know about your masters, whoever they are, but I haven't used Windows for any serious purpose since 1996. > You masters don't play DirectX games? ... I use wine to play my old Windows games under Linux; games that I can't play using wine I've simply discarded. Most of my newest games have been designed with Linux in mind from the start. Some DirectX games work fine with wine.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-11-18 11:42 -0800 |
| Message-ID | <183380cc-52da-4379-95b1-58fac3c5adb7@googlegroups.com> |
| In reply to | #96827 |
On Friday, November 18, 2016 at 9:24:10 AM UTC-5, Richard Heathfield wrote: > On 18/11/16 13:28, David Brown wrote: > > On 18/11/16 13:23, Richard Heathfield wrote: > >> On 18/11/16 12:16, David Brown wrote: > >>> [...] I have my Windows > >>> machine and my Linux machine running continuously at my office - they > >>> both have average uptimes of a couple of months or so. > >> > >> I guess, then, that you don't run Firefox on them. Either that, or you > >> have one hell of a magic wand. ... > > But restarting Firefox does not mean restarting the computer. > > It does, sometimes (at least for me). If I fail to spot in time that > Firefox's memory and CPU usage are increasing exponentially, the whole > machine freezes, and there's nothing for it but to hold down the power > button for a while. I've never run into it, and since I'm prohibited by our SA's from turning my work desktop off (they remotely update it on a nightly basis), it typically has uptimes running several months. Does this happen to you on both Windows and Linux? I only use it on Linux. > And is there an active newsgroup > where the subject is topical and likely to lead to a solution? Not a newsgroup, but probably more likely than a newsgroup to lead to a solution: <https://support.mozilla.org/en-US/questions/new/desktop>
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-19 20:37 +0000 |
| Message-ID | <o0qd4e$bo9$1@dont-email.me> |
| In reply to | #96892 |
On 18/11/16 19:42, jameskuyper@verizon.net wrote: > On Friday, November 18, 2016 at 9:24:10 AM UTC-5, Richard Heathfield wrote: >> On 18/11/16 13:28, David Brown wrote: >>> On 18/11/16 13:23, Richard Heathfield wrote: >>>> On 18/11/16 12:16, David Brown wrote: >>>>> [...] I have my Windows >>>>> machine and my Linux machine running continuously at my office - they >>>>> both have average uptimes of a couple of months or so. >>>> >>>> I guess, then, that you don't run Firefox on them. Either that, or you >>>> have one hell of a magic wand. > ... >>> But restarting Firefox does not mean restarting the computer. >> >> It does, sometimes (at least for me). If I fail to spot in time that >> Firefox's memory and CPU usage are increasing exponentially, the whole >> machine freezes, and there's nothing for it but to hold down the power >> button for a while. > > I've never run into it, and since I'm prohibited by our SA's from turning my > work desktop off (they remotely update it on a nightly basis), it typically has > uptimes running several months. Does this happen to you on both Windows and > Linux? I only use it on Linux. > >> And is there an active newsgroup >> where the subject is topical and likely to lead to a solution? > > Not a newsgroup, but probably more likely than a newsgroup to lead to a solution: > <https://support.mozilla.org/en-US/questions/new/desktop> Been there, done that, got one sleeve and the washing instruction label. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-18 12:34 +0000 |
| Message-ID | <87zikx6k6p.fsf@gmail.com> |
| In reply to | #96808 |
David Brown <david.brown@hesbynett.no> writes: >> I wrote the C containers library and an EXTENSIVE TECHNICAL >> DESCRIPTION of all the specs and code that I published. Look at the >> PDF file and you will see what I consider a technical documentation. > > The CCL documentation (I recommend you use the hyperref package when > generating the pdf - it will give the pdf a proper table of contents > and clickable links. Other than that, the document looks very > impressive) is a mixture of a tutorial on CCL and a reference for how > to use the library. gcc does not come with a reference on the > programming languages it implements (the ISO standards, or their > drafts, are available elsewhere), nor is it a tutorial on C > programming. No, it does not. But some equally awful terrible very-bad free software people do maintain CPP reference (http://en.cppreference.com/) which documents the C++ standard library every bit as well as Jacob documents his library. And of course, its fatuous to compare the quality of documentation for a library (which is absolutely crucial for library end users) and the documentation of the internals of a compiler (which is utterly irrelevant for compiler users). And, of course, whether the documentation for the internals of LCC is good or not is even more irrelevant, only a very small number of people needs to see it, wishes to see it, or is allowed to see it. The documentation for writing a new front-end for gcc may be deficient, but its *still* easier for me to write a new front-end for gcc than it is to write one for lcc.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-18 13:46 +0100 |
| Message-ID | <o0mt6v$gmj$2@dont-email.me> |
| In reply to | #96812 |
Le 18/11/2016 à 13:34, Gareth Owen a écrit : > > The documentation for writing a new front-end for gcc may be deficient, > but its *still* easier for me to write a new front-end for gcc than it > is to write one for lcc. > You wrote a new front-end for gcc? Which one, may I ask? Thanks
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-18 13:44 +0100 |
| Message-ID | <o0mt38$gmj$1@dont-email.me> |
| In reply to | #96808 |
Le 18/11/2016 à 13:16, David Brown a écrit : > When you try to make it look like the sole documentation and information > for megabytes of code is 1256 bytes of text, you are completely wrong - > and insultingly wrong. Go to the Parsing chapter in the gcc internal documentation There you will find 1256 bytes of text to explain how parsing is done. The rest is TO DO or BUGS items. See it at https://gcc.gnu.org/onlinedocs/gccint/Parsing-pass.html#Parsing-pass Parsing represents megabytes of code, it is not all gcc of course, but it is surely a big part of it. For all that there is only 1256 bytes of text. But it is impossible to discuss with you since you do not read what *I* wrote but you read only what thompson wrote about what I wrote! Please read my answer to thompson and then judge yourself.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-18 14:44 +0100 |
| Message-ID | <o0n0jf$th5$1@dont-email.me> |
| In reply to | #96814 |
On 18/11/16 13:44, jacobnavia wrote: > Le 18/11/2016 à 13:16, David Brown a écrit : >> When you try to make it look like the sole documentation and information >> for megabytes of code is 1256 bytes of text, you are completely wrong - >> and insultingly wrong. > > Go to the Parsing chapter in the gcc internal documentation > There you will find 1256 bytes of text to explain how parsing is done. > The rest is TO DO or BUGS items. > > See it at > https://gcc.gnu.org/onlinedocs/gccint/Parsing-pass.html#Parsing-pass > > Parsing represents megabytes of code, it is not all gcc of course, but > it is surely a big part of it. So what? No one expects you to understand the details of how gcc parses a language from reading that one page. It's just a little bit of information. If you want to understand how it works, you are expected to study the source code. It is complicated, but it is commented and uses descriptive names from most functions, enumerated types, etc. You will also want to study the documentation for GIMPLE and GENERIC, the internal tree structures used to hold the code in various stages through the compiler. Compilers are complicated programs. /Big/ compilers are /very/ complicated programs. If you want to get involved in developing gcc, it means joining the gcc development community, making a lot of effort searching and studying the code and documentation (on-line, off-line, mailing list archives, etc.), and talking to the people who know about how things work. > > For all that there is only 1256 bytes of text. But it is impossible to > discuss with you since you do not read what *I* wrote but you read only > what thompson wrote about what I wrote! > > Please read my answer to thompson and then judge yourself. > I read what you wrote - and it was your attitude towards Keith that prompted me to post in the first place. Usually I just ignore your anti-gcc rants, but I find the way you address Keith to be totally unjustified.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-19 01:16 +0100 |
| Message-ID | <o0o5kd$6om$1@dont-email.me> |
| In reply to | #96822 |
Le 18/11/2016 à 14:44, David Brown a écrit : > If you want to understand how it works, you are expected to study the > source code. Yes, I know. I have done that but it is very difficult. For instance I had to integrate lcc within the gcc exception handling environment. No docs, just the raw code. Feasible, yes. It took me months of effort to disassemble that C code, that is generating instructions for a virtual machine that will go up the stack at run time. I just wanted that the machine goes through my code since C has no try/catch. But it was a challenge to figure out, since the documentation of that machine (the dwarf standard) has been modified in the code without any comments. That, and the fact that the optimizations frenzy of the team led them to put optimizations in the assembler that compacted the code so that my generated opcodes were transformed into something else by an assembler geared to unknown gcc specs. Great. And I figured out. Imagine. I couldn't believe it when I finished and my example code went up through my lcc code and found the catch in a higher layer of C++. Understanding gcc's code is feasible. But it would be better with docs. It is actually not the difficulty of the thing itself (just generating something for a vm is not difficult), but that the the specs of the vm must be read from raw C code and not written anywhere was kind of frustrating experience. I asked for help and received none. People working with gcc are busy guys, and they do not answer too many questions, in any case at this level. I fear that most of the team actually doesn't even know what is going on exactly with catch/throw/stack unwinding because as soon as "it works" people are exhausted and do not document anything. As I did, I was happy when it worked but felt an irresistible urge to forget that as soon as I could.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-19 15:43 +0100 |
| Message-ID | <o0podo$f1h$1@dont-email.me> |
| In reply to | #96920 |
On 19/11/16 01:16, jacobnavia wrote: > Le 18/11/2016 à 14:44, David Brown a écrit : >> If you want to understand how it works, you are expected to study the >> source code. > > Yes, I know. I have done that but it is very difficult. For instance I > had to integrate lcc within the gcc exception handling environment. > > > No docs, just the raw code. Feasible, yes. It took me months of effort > to disassemble that C code, that is generating instructions for a > virtual machine that will go up the stack at run time. > > I just wanted that the machine goes through my code since C has no > try/catch. But it was a challenge to figure out, since the documentation > of that machine (the dwarf standard) has been modified in the code > without any comments. > > That, and the fact that the optimizations frenzy of the team led them to > put optimizations in the assembler that compacted the code so that my > generated opcodes were transformed into something else by an assembler > geared to unknown gcc specs. > > Great. > > And I figured out. Imagine. I couldn't believe it when I finished and my > example code went up through my lcc code and found the catch in a higher > layer of C++. > > Understanding gcc's code is feasible. But it would be better with docs. I am quite happy to believe that understanding gcc is hard and time-consuming. I am quite happy to believe that it would be easier with /better/ documentation. I am quite happy to believe that the quantity and quality of the documentation does not match the quantity and quality of the code in the compiler. All I object to is wildly exaggerated claims about it having /no/ documentation, or merely 1256 bytes of documentation for megabytes of source code, and unfair comparisons with completely different types of project (such as tutorial books). > It is actually not the difficulty of the thing itself (just generating > something for a vm is not difficult), but that the the specs of the vm > must be read from raw C code and not written anywhere was kind of > frustrating experience. > > I asked for help and received none. People working with gcc are busy > guys, and they do not answer too many questions, in any case at this > level. I fear that most of the team actually doesn't even know what is > going on exactly with catch/throw/stack unwinding because as soon as "it > works" people are exhausted and do not document anything. I believe there is a bit of this too, and it is not a good thing. There have been parts of gcc where developers have decided it is better to re-write this feature in a new and better way, than to understand the old code and improve on it. And there are parts of gcc code where even the experts fear to tread. It is improving (partly due to such re-writes), but I don't think it is at all unbelievable that there are few people who understand the details of a particular feature such as the catch/throw code, or that those people do not have the time for documentation and/or helping others. It would be nice if people /did/ have the time for such things, but it is always hard to find resources and money for documentation, and it is rare that people do it for fun in their free time. > > As I did, I was happy when it worked but felt an irresistible urge to > forget that as soon as I could.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-19 18:13 +0100 |
| Message-ID | <o0q176$lpi$1@dont-email.me> |
| In reply to | #96971 |
Le 19/11/2016 à 15:43, David Brown a écrit : > All I object to is wildly exaggerated claims about it having /no/ > documentation, or merely 1256 bytes of documentation for megabytes of > source code Look, go to the "Parsing" chapter of the documentation, count the bytes (eliminating the TO DO and BUGS entries) and you will see the same number of bytes as I do. It is not wildly exaggerated, it is just a fact. Look at the first two sentences that make those 1256 bytes https://gcc.gnu.org/onlinedocs/gccint/Parsing-pass.html#Parsing-pass I was talking about "The parsing pass" because that is just MEGABYTES of source, even if it is not all gcc of course.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-18 00:16 +0000 |
| Message-ID | <o0lh7u$vlk$1@dont-email.me> |
| In reply to | #96776 |
On 17/11/16 21:27, jacobnavia wrote: > Le 17/11/2016 à 20:59, Keith Thompson a écrit : >> jacobnavia <jacob@jacob.remcomp.fr> writes: >> [...] >>> When they make available the whole compiler with commented source code? >>> This is not just GNU that overwhelms us with megabytes of code where the >>> only comment is the copyright notice and no technical documentation. >>> This is a fully commented code in a top down manner, easy to get into. >> >> Are you saying gcc has no technical documentation? >> >> https://gcc.gnu.org/onlinedocs/gccint/ >> >> (I make no comment on the quality of the documentation, since I haven't >> read it.) >> > > If you haven't read it why do you say that that is documentation? > > Well obviously you say that because you haven't read it. > > For instance, just one thing that I took from that link > > <quote> > 9.1 Parsing pass > <snip> > > 1156 bytes of text, that is all. Uh, I make it about 3300 bytes (for Section 9.1), and several paragraphs rather than just two sentences. I agree with you, however, that the document is too brief and high level to be of very much value to someone trying to understand the parsing pass. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-11-18 09:25 +0100 |
| Message-ID | <o0mdst$t3m$1@dont-email.me> |
| In reply to | #96784 |
Le 18/11/2016 à 01:16, Richard Heathfield a écrit : > Uh, I make it about 3300 bytes (for Section 9.1), and several paragraphs > rather than just two sentences. I did not count the paragraphs that are titled TO DO or BUGS as documentation.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-18 18:15 +0000 |
| Message-ID | <o0ngee$ps8$1@dont-email.me> |
| In reply to | #96766 |
On 17/11/2016 19:59, Keith Thompson wrote: > jacobnavia <jacob@jacob.remcomp.fr> writes: > [...] >> When they make available the whole compiler with commented source code? >> This is not just GNU that overwhelms us with megabytes of code where the >> only comment is the copyright notice and no technical documentation. >> This is a fully commented code in a top down manner, easy to get into. > > Are you saying gcc has no technical documentation? > > https://gcc.gnu.org/onlinedocs/gccint/ In the section on GIMPLE it suggests using the -fdump-tree-gimple option to display the code in low-level, unstructured C-like format. I tried it and got something not too different from the low-level C I posted a day or two ago! (The output of my own compiler from a few years ago, based on 'three-address-code'. However I couldn't generate efficient native code from it and eventually used a different approach.) Both depend heavily on 'goto' as well. Mine however will compile as actual C; the GIMPLE output seems to be just for looking at. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-18 19:18 +0000 |
| Message-ID | <871sy8iokv.fsf@gmail.com> |
| In reply to | #96872 |
BartC <bc@freeuk.com> writes: > Both depend heavily on 'goto' as well. Mine however will compile as > actual C; the GIMPLE output seems to be just for looking at. GIMPLE is what the intermediate/final parsers use to produce object code. See the non-existent technical documentation: https://gcc.gnu.org/onlinedocs/gccint/Tree-SSA.html#Tree-SSA
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-18 08:20 +0100 |
| Message-ID | <o0ma3g$j6t$1@dont-email.me> |
| In reply to | #96763 |
On 17/11/16 20:15, jacobnavia wrote: > Le 11/11/2016 à 11:43, BartC a écrit : >> On 10/11/2016 20:29, luser droog wrote: >> >>> Dude, Fraser and Hanson. lmgtfy >>> https://smile.amazon.com/Retargetable-Compiler-Design-Implementation-1995-02-10/dp/B01JXMG072/ref=sr_1_1?s=books&ie=UTF8&qid=1478809500&sr=1-1&keywords=fraser+and+hanson >>> >>> >> > > There are other stupid comments there. For instance this one: > > A customer: > I do give them credit, though, for writing a compiler with easily > changeable back ends. > > A great thing. I could port it to the power PC and I am now porting to > ARM. Compare that to porting gcc to do a new CPU. You do know that gcc has been ported to a great deal more targets than any other compiler? The job is not always easy, though I gather it has been getting easier with newer gcc versions, and it is commonly held that it is easier to write a new backend for llvm than gcc. But the usually practice for anyone designing a new cpu architecture is to make a port of gcc before thinking about any other compiler. > > A customer: > This part is way cool, especially with such diverse platforms as Sparc > and x86. Finally, their writing is not easily read - especially with the > hokey code interspersed. > > Writing a compiler, modifying one, retargeting one are no easy tasks. > Their writing is technical writing that is difficult not because of the > writing style, but because the stuff tehy are talking about is complex > and really hard to understand. > Ah, so despite it being really easy to re-target this compiler, it is actually hard. And both count as "stupid comments". It's great that you have found a book you like, and great that you have written a compiler. But you are not doing a great job of promoting it.
[toc] | [prev] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2016-11-18 20:36 +0800 |
| Message-ID | <o0msis$e7o$2@dont-email.me> |
| In reply to | #96066 |
On 8/11/2016 7:07 PM, Thiago Adams wrote: > My question is: Do you have debug, autocomplete? > I know there are some IDEs ready for language plugins but this also requires a lot of work (time). Good C programmers don't need reminders and alerts to write a program. Everything is in their brains, no need for manuals nor help files. It's the OS, GUI, DOM ... that complicated C programming.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web