Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #61362 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2015-05-01 17:55 -0700 |
| Last post | 2015-05-03 10:58 -0700 |
| Articles | 13 on this page of 73 — 16 participants |
Back to article view | Back to comp.lang.c
Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-01 17:55 -0700
Re: Understandability Keith Thompson <kst-u@mib.org> - 2015-05-01 19:41 -0700
Re: Understandability wssimms@gmail.com - 2015-05-01 20:45 -0700
Re: Understandability Bartc <bc@freeuk.com> - 2015-05-02 10:38 +0100
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-02 09:15 -0700
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-04 09:26 +0200
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-04 12:52 -0700
Re: Understandability Noob <root@127.0.0.1> - 2015-05-02 14:21 +0200
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-02 09:13 -0700
Re: Understandability Ian Collins <ian-news@hotmail.com> - 2015-05-03 08:07 +1200
Re: Understandability Keith Thompson <kst-u@mib.org> - 2015-05-02 13:11 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-03 10:50 -0700
Re: Understandability Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 13:26 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-04 12:29 -0700
Re: Understandability Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-05 05:47 -0700
Re: Understandability raltbos@xs4all.nl (Richard Bos) - 2015-05-08 21:10 +0000
Re: Understandability Ian Collins <ian-news@hotmail.com> - 2015-05-09 09:17 +1200
Re: Understandability Keith Thompson <kst-u@mib.org> - 2015-05-08 14:32 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-09 09:13 -0700
Re: Understandability Keith Thompson <kst-u@mib.org> - 2015-05-09 16:48 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-10 11:05 -0700
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-11 08:48 +0200
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:55 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-11 17:52 -0400
Re: Understandability glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-11 22:54 +0000
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-12 08:49 +0200
Re: Understandability Morris Dovey <mrdovey@iedu.com> - 2015-05-12 02:15 -0500
Re: Understandability Phil Carmody <pc+usenet@asdf.org> - 2015-05-25 03:15 +0300
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-25 00:45 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 10:26 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 10:06 -0700
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-12 08:59 +0200
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-12 08:37 -0700
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-13 08:53 +0200
Re: Understandability Keith Thompson <kst-u@mib.org> - 2015-05-13 08:16 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-13 09:49 -0700
Re: Understandability Keith Thompson <kst-u@mib.org> - 2015-05-13 10:53 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-14 10:35 -0700
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-13 09:31 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-13 13:10 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-14 10:27 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-14 22:51 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-15 10:02 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-15 13:37 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-16 09:18 -0700
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-16 23:56 +0200
Re: Understandability gazelle@shell.xmission.com (Kenny McCormack) - 2015-05-17 12:45 +0000
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-17 09:16 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-17 12:47 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-18 10:54 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-18 15:00 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-19 09:49 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-19 13:10 -0400
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-16 19:01 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-17 09:30 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-17 12:58 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-18 10:54 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-18 14:56 -0400
Re: Understandability David Kleinecke <dkleinecke@gmail.com> - 2015-05-19 09:46 -0700
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-19 13:16 -0400
Re: Understandability Richard Heathfield <rjh@cpax.org.uk> - 2015-05-19 18:23 +0100
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-19 14:02 -0400
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-19 00:11 +0200
Re: Understandability James Kuyper <jameskuyper@verizon.net> - 2015-05-18 18:28 -0400
Re: Understandability Keith Thompson <kst-u@mib.org> - 2015-05-15 10:52 -0700
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-13 21:53 +0200
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-09 16:18 +0200
Re: Understandability Noob <root@127.0.0.1> - 2015-05-09 18:31 +0200
Re: Understandability raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:44 +0000
Re: Understandability glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-17 15:53 +0000
Re: Understandability David Brown <david.brown@hesbynett.no> - 2015-05-04 09:15 +0200
Re: Understandability Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2015-05-16 00:28 +0000
Re: Understandability Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 10:58 -0700
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-19 18:23 +0100 |
| Message-ID | <mjfrg5$arl$1@dont-email.me> |
| In reply to | #62308 |
On 19/05/15 18:16, James Kuyper wrote: > On 05/19/2015 12:46 PM, David Kleinecke wrote: > ... >> The kinds of pipes are just two different ways of doing the same thing. >> Obviously you can't use a within-one-process pattern to do things wiht >> two processes and vice versa. > > The second sentence contradicts the first. Consider: Going from Lands End to Duncansby Head by boat or trail-bike are just two different ways of doing the same thing. Obviously you can't drive a trail-bike on water or sail a boat on land. After reflecting on the above, do you still think the second sentence contradicts the first? >> I fear you don't understand what I am talking about. > > I understand that it's not worthwhile talking with you any more. That's up to you, but the dismissal seems uncharacteristically rapid and abrupt. Bad day? -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-19 14:02 -0400 |
| Message-ID | <555B7ACB.80607@verizon.net> |
| In reply to | #62309 |
On 05/19/2015 01:23 PM, Richard Heathfield wrote: > On 19/05/15 18:16, James Kuyper wrote: >> On 05/19/2015 12:46 PM, David Kleinecke wrote: >> ... >>> The kinds of pipes are just two different ways of doing the same thing. >>> Obviously you can't use a within-one-process pattern to do things wiht >>> two processes and vice versa. >> >> The second sentence contradicts the first. > > Consider: Going from Lands End to Duncansby Head by boat or trail-bike > are just two different ways of doing the same thing. Obviously you can't > drive a trail-bike on water or sail a boat on land. > > After reflecting on the above, do you still think the second sentence > contradicts the first? As you pointed out, a boat cannot be used to travel the bike trail, and the bike can't be used to cross the water, so the "practical effect" is not "the same", to go back to the original wording. The practical effect is quite different, depending upon which one you use. Only the net result is the same - but it does make a difference how you got there. "practical" inherently includes consideration of issues like travel time, safety, and cost, which are not at all the same for the two methods. >>> I fear you don't understand what I am talking about. >> >> I understand that it's not worthwhile talking with you any more. > > That's up to you, but the dismissal seems uncharacteristically rapid and > abrupt. ... Perhaps it seems that way to you, but I've been building up to that dismissal ever since he first used the "practical effect" is "the same" wording. > ... Bad day? That's certainly a factor. I've got premature twins suffering from gastric reflux keeping me busy lately.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-05-19 00:11 +0200 |
| Message-ID | <mjdo13$cpu$1@dont-email.me> |
| In reply to | #62135 |
On 17/05/15 01:01, James Kuyper wrote: > On 05/16/2015 12:18 PM, David Kleinecke wrote: >> On Friday, May 15, 2015 at 10:37:48 AM UTC-7, James Kuyper wrote: > ... >>> Could you describe the distinction between those formal and informal >>> meanings? I would assume, in context, that both Keith and David were >>> referring to what, on typical Unix-like systems, results from using the >>> "mkfifo" command or the "|" symbol at the command line, or the pipe() or >>> popen() functions in C code. Those are four different ways of invoking >>> the same feature of the operating system. Does that differ from your >>> expectations? >> >> These are all examples of what I called formal pipes. Informal pipes >> involve situations where one piece of code gets data from another by >> (usually) next_token or the like calls. I call these pull pipes. There >> are also push pipes where one code piece sends data along by a >> handle_token call. > > Could you identify the context in which next_token and handle_token > apply (just like I did above, when I said "typical Unix-like system", > "command line", and "functions in C code")? On my desktop machine, the > 'man' command gives me nothing for either of those names. A google > search gives me too many hits, none of them obviously the one you were > talking about. > >> The practical effect of both kinds of pipes is the same. > > David Brown does recognize the token routines you are talking about, and > says they can only be used for intra-process communication, whereas > pipes can also be used for inter-process communication. If he's right, > that's a huge difference, given that almost all uses of pipes that I'm > familiar with are for inter-process communication. I've seen pipes used > for intra-process communication, but it was merely a neat trick, not > something that was actually reasonable to do. > I didn't "recognize" the token routines he mentioned - I merely guessed that their are normal functions which pass bits of data round within a single process (but conceivably between threads in the same process). I could well be wrong, but that's what it sounded like to me.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-18 18:28 -0400 |
| Message-ID | <555A6771.1000805@verizon.net> |
| In reply to | #62251 |
On 05/18/2015 06:11 PM, David Brown wrote: > On 17/05/15 01:01, James Kuyper wrote: ... >> David Brown does recognize the token routines you are talking about, and >> says they can only be used for intra-process communication, whereas >> pipes can also be used for inter-process communication. If he's right, >> that's a huge difference, given that almost all uses of pipes that I'm >> familiar with are for inter-process communication. I've seen pipes used >> for intra-process communication, but it was merely a neat trick, not >> something that was actually reasonable to do. >> > > I didn't "recognize" the token routines he mentioned - I merely guessed > that their are normal functions which pass bits of data round within a > single process (but conceivably between threads in the same process). I > could well be wrong, but that's what it sounded like to me. Sorry - you sounded so sure that I didn't realize you were guessing. While he hasn't directly responded to my questions on that point, his comments have been consistent with your guesses - in particular, his comment about re-writing grep.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-15 10:52 -0700 |
| Message-ID | <87mw15bueq.fsf@kst-u.example.com> |
| In reply to | #62050 |
David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> "Pipe" has a formal and an informal meaning. I intended it formally when
> I made that statement. I doubt that gcc uses formal pipes - but it surely
> pipes in the informal sense.
Why do you doubt it? gcc doesn't use "formal" pipes by default, but it
has a "-pipe" option that does exactly that:
'-pipe'
Use pipes rather than temporary files for communication between
the various stages of compilation. This fails to work on some
systems where the assembler is unable to read from a pipe; but
the GNU assembler has no trouble.
I'm pretty sure that's already been mentioned in this thread.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-05-13 21:53 +0200 |
| Message-ID | <mj0a20$q9s$1@dont-email.me> |
| In reply to | #61942 |
On 13/05/15 18:31, David Kleinecke wrote: > On Tuesday, May 12, 2015 at 11:54:00 PM UTC-7, David Brown wrote: >> >> If I remember the history of this thread correctly (and perhaps I >> remember /incorrectly/), the key objection was that you wrote "Gnu is >> right to call their work a collection. It is really a fiction that gcc >> is a free-standing program." You followed this with a series of >> misconceptions about gcc and the way it works. >> >> I don't think anyone objects to calling gcc a "program", and we can all >> be happy with only a vague definition of "program". (I doubt that this >> group could ever agree on a precise definition of "program" !) > > I protest once again. I believe I understand what gcc is doing. If you > feel I have "misconceptions" please tell me what they are. It is possible > I do have misconceptions. > Technically, we could both be right here - I said that you /had/ misconceptions, and you say that you understand the details of what gcc is doing. If you have learned as a result of the information given in this thread, and know have better knowledge, then that's great! I expect you know roughly what gcc is doing, but you were wrong in your descriptions of some of the details (James made a nice summary post). People seldom bother with these sorts of internal details of the compiler, so it does not normally matter - but if you /do/ want to go into detail, it's good to get it right.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-05-09 16:18 +0200 |
| Message-ID | <mil4u7$lp1$1@dont-email.me> |
| In reply to | #61786 |
On 08/05/15 23:10, Richard Bos wrote: > Keith Thompson <kst-u@mib.org> wrote: > >> David Kleinecke <dkleinecke@gmail.com> writes: > >>> Gnu is right to call their work a collection. It is really a fiction >>> that gcc is a free-standing program. >> >> Saying it's a "fiction" implies that someone is making that claim. > > The claim has been made, repeatedly, in this very newsgroup, that gcc > and glib are completely separate programs and systems which should never > be assumed to be used together and a fault of the Ganuck system is not a > fault of the Ganuck system at all, really, honestly, and we're not > trying to embrace-and-extent, oh no, pinky swear guv'. > > Fiction? Or simple dishonesty on the part of the Stallmaniados? > > Richard > For most of my work, I use gcc - but I almost never use glibc for development. Yes, they are separate projects handled by separate groups and developed in different ways - though obviously there is a certain degree of cooperation.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2015-05-09 18:31 +0200 |
| Message-ID | <milcmq$kn0$1@dont-email.me> |
| In reply to | #61786 |
Richard Bos wrote: > The claim has been made, repeatedly, in this very newsgroup, that gcc > and glib are completely separate programs and systems which should never > be assumed to be used together and a fault of the Ganuck system is not a > fault of the Ganuck system at all, really, honestly, and we're not > trying to embrace-and-extent, oh no, pinky swear guv'. > > Fiction? Or simple dishonesty on the part of the Stallmaniados? What. The. Flying. Fuck. You can't even get the projects' names right. https://developer.gnome.org/glib/stable/ https://www.gnu.org/software/libc/ Take your GNU trolling to comp.os.linux.advocacy Plonk.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-05-17 10:44 +0000 |
| Message-ID | <55586fb4.5959046@news.xs4all.nl> |
| In reply to | #61807 |
Noob <root@127.0.0.1> wrote: > Richard Bos wrote: > > > The claim has been made, repeatedly, in this very newsgroup, that gcc > > and glib are completely separate programs and systems which should never > > be assumed to be used together and a fault of the Ganuck system is not a > > fault of the Ganuck system at all, really, honestly, and we're not > > trying to embrace-and-extent, oh no, pinky swear guv'. > > > > Fiction? Or simple dishonesty on the part of the Stallmaniados? > > What. The. Flying. Fuck. > > You can't even get the projects' names right. My point is that, in a fundamental sense, the project's name is Gnu C, and separating it into parts _and insisting that those are completely separate_ is disingenuous. Yes, you can use a different library with gcc-the-compiler-backend-or- driver-or-whatever-it-is. Yes, you can use glibc with a different compiler. So? You can do so with several other implementations, but nobody pretends that _those_ aren't specific, intended implementations. > Take your GNU trolling to comp.os.linux.advocacy Take your Ganuck _advocacy_ to that newsgroup. That's what it's for. I'm sick of this hypocrisy. The Stallman crowd gets away with things they'd have been called out on long, long ago if they weren't Stallmaniados. Nobody wants to see that the GNU Company is nearly as evil, and even more embrace-and-extend happy, than even Micro$oft. It's time we applied the same cluestick to both sides, and called the "Free" (as long as you agree with them, of course) Software crowd out for their close similarity to their "enemies". Richard
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-17 15:53 +0000 |
| Message-ID | <mjadgs$qkg$1@speranza.aioe.org> |
| In reply to | #62147 |
Richard Bos <raltbos@xs4all.nl> wrote: (snip) >> Richard Bos wrote: >> > The claim has been made, repeatedly, in this very newsgroup, that gcc >> > and glib are completely separate programs and systems which should never >> > be assumed to be used together and a fault of the Ganuck system is not a >> > fault of the Ganuck system at all, really, honestly, and we're not >> > trying to embrace-and-extent, oh no, pinky swear guv'. > My point is that, in a fundamental sense, the project's name is Gnu C, > and separating it into parts _and insisting that those are completely > separate_ is disingenuous. > Yes, you can use a different library with gcc-the-compiler-backend-or- > driver-or-whatever-it-is. Yes, you can use glibc with a different > compiler. So? You can do so with several other implementations, but > nobody pretends that _those_ aren't specific, intended implementations. As well as I remember, gcc existed long before glibc. In the beginning, gcc existed along with OS supplied C compilers, and OS supplied libc. For many years, unix always came with a C compiler, as one was required to sysgen the kernel. At some point, vendors decided to sell the C compiler separately, and supplied a minimal C compiler for sysgen. Even so, libc was usually supplied, especially when dynamic linking was used. By now, it might be rare to use the system (closed source) libc with gcc. -- glen
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-05-04 09:15 +0200 |
| Message-ID | <mi769d$ip9$1@dont-email.me> |
| In reply to | #61389 |
On 02/05/15 18:13, David Kleinecke wrote: > On Saturday, May 2, 2015 at 5:21:48 AM UTC-7, Noob wrote: >> On 02/05/2015 04:05, Stefan Ram wrote: >> >>> Then restrict your search to wikipedia. >> >> Indeed! >> >> https://en.wikipedia.org/wiki/GNU_Compiler_Collection >> >>> The GNU Compiler Collection (GCC) is a compiler system produced by >>> the GNU Project supporting various programming languages. GCC is a >>> key component of the GNU toolchain. >> >> https://en.wikipedia.org/wiki/Compiler >> >>> A compiler is a computer program (or set of programs) that transforms >>> source code written in a programming language (the source language) >>> into another computer language (the target language, often having a >>> binary form known as object code). The most common reason for >>> converting a source code is to create an executable program. >> >> Regards. > > The Wikipedia page on "GNU Compiler Collection" is very poorly written > and is an excellent example of what I deplore. Feel free to read it anyway - it's better than guessing about it. > > The definition on the "Compiler" is an excellent example of what I want. > A description of gcc might well start with that definition (edited > perhaps), then follow up: > The program gcc is a compiler for programs written in C programming > language. The C language is described in ... > But gcc is not a "compiler for programs written in C" - it is a compiler for a variety of languages (C, C++, java, go, fortran, Ada - IIRC), a run-time library (/not/ the standard C library, but the compiler support library), and a driver program that will also invoke assemblers and linkers as needed. > Gnu is right to call their work a collection. It is really a fiction > that gcc is a free-standing program. Gnu call it a "compiler collection" because it is a collection of compilers for different languages. No one has ever thought of it as a free-standing program, even when it was a pure C compiler - compilers are very rarely single programs. The program "gcc" itself is not even the compiler - it is a "driver" program that passes data and options around amongst the various parts of the suite to handle compilation and (usually) assembly and linking. > There are two parts - the front > and back ends. Three parts - there is also the "middle end". (And the assembler and linker come in addition - they are normally from binutils rather than gcc.) > The front end produces a "source program" in an > intermediate language which the back end "assembles" into machine code. Nope. The "front end" is specific to the source code language, such as C, C++, Fortran, etc. It produces an intermediate language (GIMPLE), which is passed on to the "middle end" where much of the optimisation work takes place. The middle-end is /mostly/ independent of both the back-end target and the front-end language, but there is a certain amount of cross-talk between the parts. (llvm has a similar theoretical structure, but has much cleaner separation between the parts.). The output from the middle-end is another intermediate language (RTL). The back-end handles the target-specific register allocation and code generation. The result is assembly, not machine code - an external assembler (usually "gas" from binutils) is called to generate the machine code. Then another external program (usually "ln" from binutils) is called to link the object code and static libraries into an executable. (Things are a little more complicated when using link-time optimisation, but lets skip that for now.) > GNU, I believe, uses a Lisplike language called RTL. One way to make > gcc a true program would be to make the back end a subroutine called at > the end of front processing. A pipe might be a better idea. > Pipes /are/ the usual way of passing data and options between the passes inside gcc. Intermediary files are only stored if you ask for them (typically for debugging gcc itself).
[toc] | [prev] | [next] | [standalone]
| From | Waldek Hebisch <hebisch@math.uni.wroc.pl> |
|---|---|
| Date | 2015-05-16 00:28 +0000 |
| Message-ID | <mj62v3$bq$1@z-news2.pwr.wroc.pl> |
| In reply to | #61481 |
David Brown <david.brown@hesbynett.no> wrote:
> On 02/05/15 18:13, David Kleinecke wrote:
> > On Saturday, May 2, 2015 at 5:21:48 AM UTC-7, Noob wrote:
> >> On 02/05/2015 04:05, Stefan Ram wrote:
> >>
>
> > Gnu is right to call their work a collection. It is really a fiction
> > that gcc is a free-standing program.
>
> Gnu call it a "compiler collection" because it is a collection of
> compilers for different languages. No one has ever thought of it as a
> free-standing program, even when it was a pure C compiler - compilers
> are very rarely single programs.
>
> The program "gcc" itself is not even the compiler - it is a "driver"
> program that passes data and options around amongst the various parts of
> the suite to handle compilation and (usually) assembly and linking.
>
> > There are two parts - the front
> > and back ends.
>
> Three parts - there is also the "middle end". (And the assembler and
> linker come in addition - they are normally from binutils rather than gcc.)
>
> > The front end produces a "source program" in an
> > intermediate language which the back end "assembles" into machine code.
>
> Nope. The "front end" is specific to the source code language, such as
> C, C++, Fortran, etc. It produces an intermediate language (GIMPLE),
> which is passed on to the "middle end" where much of the optimisation
> work takes place.
>
> The middle-end is /mostly/ independent of both the back-end target and
> the front-end language, but there is a certain amount of cross-talk
> between the parts. (llvm has a similar theoretical structure, but has
> much cleaner separation between the parts.). The output from the
> middle-end is another intermediate language (RTL).
>
> The back-end handles the target-specific register allocation and code
> generation. The result is assembly, not machine code - an external
> assembler (usually "gas" from binutils) is called to generate the
> machine code. Then another external program (usually "ln" from
^^
"ld"
> binutils) is called to link the object code and static libraries into an
> executable.
>
> (Things are a little more complicated when using link-time optimisation,
> but lets skip that for now.)
>
> > GNU, I believe, uses a Lisplike language called RTL. One way to make
> > gcc a true program would be to make the back end a subroutine called at
> > the end of front processing. A pipe might be a better idea.
> >
>
> Pipes /are/ the usual way of passing data and options between the passes
> inside gcc. Intermediary files are only stored if you ask for them
> (typically for debugging gcc itself).
>
_Options_ are passed as argument strings (argv in main). In reasonably
modern GCC pipes are only used between backend and assembler. AFAIK
linker always takes files. The rest, that is preprocessor, front
end, middle end and backend execute in single process and communicate
via function calls sharing data structures. To David was right
writing that pipes are not used between front end and middle end
or backend. But was wrong thinking that they are separate programs
communicating via files.
--
Waldek Hebisch
hebisch@antispam.uni.wroc.pl
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-03 10:58 -0700 |
| Message-ID | <kfn4mntmtl6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61362 |
David Kleinecke <dkleinecke@gmail.com> writes: > I googled "gcc tutorial" and looked at each hit. Two of the hits on > the first page are not really about gcc. Here are the title and first > sentence of the of the other hits: > > [snip] > > Not a single one starts with a statement about what gcc is and does. > A tutorial is for beginners and I would expect a tutorial for gcc to > begin more or less like > > Gcc is a computer program that reads human-readable program code > and rewrites (compiles) it as code the machine understand. It is > called a compiler. > > The state of art of describing computer programs seems to be abysmal. All writing inevitably leaves something out. Just because a particular document doesn't have the information you want doesn't mean the writing in it is bad; it may simply have been written for a different audience.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web