Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #89835 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2016-06-29 10:36 -0700 |
| Last post | 2016-07-01 12:09 +0100 |
| Articles | 6 on this page of 66 — 13 participants |
Back to article view | Back to comp.lang.c
Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-29 10:36 -0700
Re: Forward declarations ... the straw that broke the camel's back supercat@casperkitty.com - 2016-06-29 16:04 -0700
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-29 16:30 -0700
Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-29 19:52 -0700
Re: Forward declarations ... the straw that broke the camel's back Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-30 13:00 +0100
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 05:42 -0700
Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 18:11 +0100
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 10:30 -0700
Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 19:54 +0100
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 12:31 -0700
Re: Forward declarations ... the straw that broke the camel's back Ian Collins <ian-news@hotmail.com> - 2016-07-01 07:59 +1200
Re: Forward declarations ... the straw that broke the camel's back Gareth Owen <gwowen@gmail.com> - 2016-06-30 21:31 +0100
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 14:19 -0700
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 14:31 -0700
Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 21:18 +0100
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 14:26 -0700
Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 22:44 +0100
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 17:23 -0700
Re: Forward declarations ... the straw that broke the camel's back David Brown <david.brown@hesbynett.no> - 2016-07-05 21:38 +0200
Re: Forward declarations ... the straw that broke the camel's back Richard Heathfield <rjh@cpax.org.uk> - 2016-07-05 21:05 +0100
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-05 13:32 -0700
Re: Forward declarations ... the straw that broke the camel's back David Brown <david.brown@hesbynett.no> - 2016-07-05 23:20 +0200
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-05 14:25 -0700
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-05 16:14 -0700
Re: Forward declarations ... the straw that broke the camel's back David Brown <david.brown@hesbynett.no> - 2016-07-06 11:18 +0200
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-06 03:36 -0700
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-05 16:23 -0700
Re: Forward declarations ... the straw that broke the camel's back David Brown <david.brown@hesbynett.no> - 2016-07-06 11:29 +0200
Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-06 02:49 -0700
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-06 05:18 -0700
Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-07-06 13:57 +0100
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-06 06:24 -0700
Re: Forward declarations ... the straw that broke the camel's back David Brown <david.brown@hesbynett.no> - 2016-07-06 15:22 +0200
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-06 07:12 -0700
Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-06 08:08 -0700
Re: Forward declarations ... the straw that broke the camel's back supercat@casperkitty.com - 2016-07-06 09:00 -0700
Re: Forward declarations ... the straw that broke the camel's back Ian Collins <ian-news@hotmail.com> - 2016-07-07 08:01 +1200
Re: Forward declarations ... the straw that broke the camel's back supercat@casperkitty.com - 2016-07-06 13:30 -0700
Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-07-06 17:30 +0100
Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 00:39 +0100
Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-06-30 22:08 +0200
Re: Forward declarations ... the straw that broke the camel's back gordonb.h5sc5@burditt.org (Gordon Burditt) - 2016-06-29 20:52 -0500
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-29 19:00 -0700
Re: Forward declarations ... the straw that broke the camel's back Ian Collins <ian-news@hotmail.com> - 2016-06-30 16:06 +1200
Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-30 02:48 -0700
Re: Forward declarations ... the straw that broke the camel's back Ian Collins <ian-news@hotmail.com> - 2016-06-30 23:25 +1200
Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-30 04:39 -0700
Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-06-30 21:50 +0200
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 06:49 -0700
Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-06-30 22:23 +0200
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-04 10:43 -0700
Vaporware (Was: Forward declarations ... the straw that broke ...) gazelle@shell.xmission.com (Kenny McCormack) - 2016-07-04 17:59 +0000
Re: Forward declarations ... the straw that broke the camel's back Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-06 12:38 -0500
Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-06 11:38 -0700
Re: Forward declarations ... the straw that broke the camel's back Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-30 19:51 +0100
Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-06-30 21:59 +0200
Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-01 01:05 -0700
Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 11:32 +0100
Re: Forward declarations ... the straw that broke the camel's back Ian Collins <ian-news@hotmail.com> - 2016-06-30 23:23 +1200
Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 14:28 +0100
Re: Forward declarations ... the straw that broke the camel's back supercat@casperkitty.com - 2016-06-30 08:24 -0700
Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 16:56 +0100
Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-06-30 22:17 +0200
Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 22:22 +0100
Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-01 08:25 +0200
Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-07-01 12:09 +0100
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-30 08:24 -0700 |
| Message-ID | <849a6b03-ea90-4bed-b9f5-4b96ec3d4d18@googlegroups.com> |
| In reply to | #89859 |
On Thursday, June 30, 2016 at 8:28:38 AM UTC-5, Bart wrote: > How do you share declarations then across modules? One approach which can work well is to have the compilation process produce, either as two separate files or combined into one, a collection of information similar to what a .h file would contain, along with a bunch of object code. The compiler can produce the first blob of information from a source file without needing to resolve any external dependencies, so the compiler can start by running every source file through the initial scan process. Since that process doesn't rely upon any dependencies, the files can be processed in any order. Next, the compiler can read in the phase-1 output associated with every file it's dependent upon and and resolve all dependencies involving that information, whereupon it can then proceed to generate code for that source file. Unless the source file has changed since it went through phase-1, the definitions blob should be unaffected by this process, so this process can be done on all files in any order. To expedite rebuilds, the compiler can keep for each project a list with the timestamps of every file and a hash of the exported information associated with it, and can keep for each file a unified cache of all data associated with imported declarations info and the hashes thereof, thus minimizing the number of files that would have to be opened on most builds. That doesn't sound very impractical to me.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-30 16:56 +0100 |
| Message-ID | <nl3ff1$dg6$1@dont-email.me> |
| In reply to | #89861 |
On 30/06/2016 16:24, supercat@casperkitty.com wrote: > On Thursday, June 30, 2016 at 8:28:38 AM UTC-5, Bart wrote: >> How do you share declarations then across modules? > > One approach which can work well is to have the compilation process > produce, either as two separate files or combined into one, a > collection of information similar to what a .h file would contain, > along with a bunch of object code. The compiler can produce the first > blob of information from a source file without needing to resolve any > external dependencies, so the compiler can start by running every > source file through the initial scan process. Since that process > doesn't rely upon any dependencies, the files can be processed in any > order. Are you talking about compiling a language like C as it is now? In that case that runs into difficulties because A may depend on imports from B, and B depends on imports from A. (Imagine one large module split into two mutually dependent ones.) You might not compile, or even partially compile A, because it depends on stuff from B. And vice versa. That's solved now by creating a common header H where such problematic declarations are written manually, before either A or B is compiled. That works well, but you have to deal with the forward and duplication declarations that have been complained about. (Outside of C, I've tried several schemes where duplicated declarations are largely eliminated, and most declarations within a file or functions can be out of order. However, that requires a strict hierarchical module structure, and can need a full re-compile in strict order. But from time to time it is necessary to access names across the hierarchy, and then it is necessary to resort to manually written declarations, breaking the one-definition rule. But that's a tiny fraction of all declarations. Another scheme I've played with does a non-compiling 'pre-pass' of source files as needed, generating an exports file (like the information file in your proposal). That introduces some restrictions in what can be shared across modules, but it will cope with circular imports. (With the extra convenience that with modules M1 to M10, each can simply import all the other modules; even itself so that the set of imports is the same in each file.) What I'm looking at now is to simply recompile everything in a project, but again with a strict module hierarchy. But that requires a very fast compiler (so that a typical project can be re-built from scratch in a fraction of a second). The trouble is none of these schemes is as simple as the way that C compilers work now, primitive thought it might be.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-06-30 22:17 +0200 |
| Message-ID | <nl3uop$6nb$1@dont-email.me> |
| In reply to | #89859 |
Le 30/06/2016 à 15:28, BartC a écrit : > If there is a global function F used by all 50 modules M1 to M50, you > either declare F in a single header H included in all M modules, or you > have to duplicate the declaration for F in M1 to M50, possibly by > creating headers H1 to H50. Wait, we are speaking about structured programming isn't it? You make modules, for instance in the lcc-win system I have some headers like: "debugger.h" "editor.h" "make.h" etc. There is a general wedit.h file that contains all shared functions but those change rarely. This has the advantage of hiding debugger functions from the editor and viceversa. What are we speaking about? The compilation of a 5 000 line source file including some headers, etc takes 0.78 seconds using lcc-win. In a 50 000 line project a full recompilation would take you the staggering time of around 7.8 seconds, an eternity. And even in the case of recompiling a 500 000 line project it would be just over a minute... Engineering means building things with available tools and finding solutions to problems. Making your system more modular would solve this problem.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-30 22:22 +0100 |
| Message-ID | <nl42ja$k8a$1@dont-email.me> |
| In reply to | #89873 |
On 30/06/2016 21:17, jacobnavia wrote: > Le 30/06/2016 à 15:28, BartC a écrit : >> If there is a global function F used by all 50 modules M1 to M50, you >> either declare F in a single header H included in all M modules, or you >> have to duplicate the declaration for F in M1 to M50, possibly by >> creating headers H1 to H50. > > Wait, we are speaking about structured programming isn't it? > > You make modules, for instance in the lcc-win system I have some headers > like: > > "debugger.h" > "editor.h" > "make.h" > Yes, and if you have 50 of those, then each module will need to include up to 0 to 50 headers (between 0 and 2500 includes in all). If 17 modules include "editor.h", then those 17 will need recompiling when editor.c changes. So you still have the problem of dependencies requiring multiple recompiles; it doesn't solve it as Ian Collins was suggesting. > What are we speaking about? > The compilation of a 5 000 line source file including some headers, etc > takes 0.78 seconds using lcc-win. In a 50 000 line project a full > recompilation would take you the staggering time of around 7.8 seconds, > an eternity. 7.8 seconds is long enough that I would actually find something else to do while waiting. (Check an on-line forum, etc.) 6K lines per second sounds remarkably low for a C compiler written in C (presumably). I'm working on compiler projects now that I estimate could achieve 500Klps for compiling source code to in-memory native code (I've managed 0.8 to 1.0Mlps for compiling byte-code). That 50,000-line project would be compiled entirely in 0.1 seconds. (Although, if it's C source code, that can introduce extra challenges; see below.) > > And even in the case of recompiling a 500 000 line project it would be > just over a minute... And 1 second for this one! (Figures include reading source code into memory, but assume file-caching by the OS has taken place. They exclude writing out code to an executable file. However code could also be fixed-up to run directly in memory.) There is a C compiler called Tiny C which also has compile times into six figures per second. But as I suggested above, having to keep recompiling the header files can use up much of that throughput. That's why it's good to discuss possible alternatives to C's header system. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-01 08:25 +0200 |
| Message-ID | <nl52di$95n$1@dont-email.me> |
| In reply to | #89878 |
Le 30/06/2016 à 23:22, BartC a écrit : > 7.8 seconds is long enough that I would actually find something else to > do while waiting. (Check an on-line forum, etc.) > In 8 seconds? > 6K lines per second sounds remarkably low for a C compiler written in C > (presumably). > Well, that's twice gcc speed and 30% faster than MSVC. Note that I am not just *parsing* some code, I am generating object files for that code! > I'm working on compiler projects now that I estimate could achieve > 500Klps for compiling source code to in-memory native code (I've managed > 0.8 to 1.0Mlps for compiling byte-code). Of course lcc-win's JIT is much faster than that! I am counting file opening, reading from disk and writing the object file with debug information
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-01 12:09 +0100 |
| Message-ID | <nl5j10$s2d$1@dont-email.me> |
| In reply to | #89895 |
On 01/07/2016 07:25, jacobnavia wrote: > Le 30/06/2016 à 23:22, BartC a écrit : >> 6K lines per second sounds remarkably low for a C compiler written in C >> (presumably). >> > > > Well, that's twice gcc speed and 30% faster than MSVC. Note that I am > not just *parsing* some code, I am generating object files for that code! I think you're underestimating the speed of lcc. Or maybe you have a very slow machine. I just have an ordinary Windows PC, and on a 20-module 30Kloc project, I'm getting about 25Kloc throughput. That includes IDE overheads of invoking the compiler 20 times in succession. gcc manages 2.2/3.5Klps for optimised/non-optimised. (And clang about 1.3Klps!). (For ~34Kloc as gcc standard headers are bigger.) > Note that I am > not just *parsing* some code, I am generating object files for that code! Sure, but I can parse source code at 1 to 2 million lines a second. Something is happening to reduce throughput by a further two magnitudes! Or three magnitudes in the case of clang. Anyway, even if compiling a whole project takes only a few seconds, I'm working on eliminating even that with build times of effectively zero. -- Bartc
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web