Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #136342 > unrolled thread
| Started by | Bart <bc@freeuk.com> |
|---|---|
| First post | 2018-10-06 15:13 +0100 |
| Last post | 2018-10-11 23:18 -0700 |
| Articles | 20 on this page of 147 — 22 participants |
Back to article view | Back to comp.lang.c
software disenchantment Bart <bc@freeuk.com> - 2018-10-06 15:13 +0100
Re: software disenchantment David Kleinecke <dkleinecke@gmail.com> - 2018-10-06 09:54 -0700
Re: software disenchantment Thiago Adams <thiago.adams@gmail.com> - 2018-10-06 10:26 -0700
Re: software disenchantment fir <profesor.fir@gmail.com> - 2018-10-14 04:26 -0700
Re: software disenchantment antispam@math.uni.wroc.pl - 2018-10-09 18:20 +0000
Re: software disenchantment David Kleinecke <dkleinecke@gmail.com> - 2018-10-09 11:54 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-09 21:22 +0100
Re: software disenchantment David Kleinecke <dkleinecke@gmail.com> - 2018-10-09 17:47 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 11:28 +0100
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 11:38 +0100
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-10 05:49 -0700
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-10 15:47 +0200
Re: software disenchantment "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-10 09:58 -0400
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 14:39 +0000
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-10 09:42 -0700
Re: software disenchantment "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-10 13:18 -0400
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 20:31 +0100
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-10 17:53 -0500
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 10:06 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 02:34 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 12:03 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 03:59 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 16:56 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 09:02 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 19:39 +0200
Re: software disenchantment Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-15 19:53 +0000
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-16 03:54 -0500
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 20:25 +0200
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 13:16 +0000
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 07:15 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 17:05 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 09:15 -0700
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 17:33 +0000
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 19:53 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 17:59 +0100
Re: software disenchantment nobody@example.org (Scott) - 2018-10-10 16:53 +0000
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-10 12:45 -0500
Re: software disenchantment Thiago Adams <thiago.adams@gmail.com> - 2018-10-10 11:04 -0700
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-10 14:22 -0500
Re: software disenchantment "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-10 15:53 -0400
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 09:06 +1300
Re: software disenchantment "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-10 13:21 -0700
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 20:27 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 22:54 +0100
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 11:01 +1300
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 11:05 +1300
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 23:16 +0100
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 11:22 +1300
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-10 23:28 +0100
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 11:33 +1300
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 11:37 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 11:50 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 14:10 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 05:24 -0700
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 15:12 +0200
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 13:13 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 14:44 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 16:38 +0200
Re: software disenchantment mark.bluemel@gmail.com - 2018-10-11 08:09 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 17:43 +0100
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 17:36 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 18:56 +0100
Re: software disenchantment Keith Thompson <kst-u@mib.org> - 2018-10-11 11:54 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 20:09 +0100
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 13:10 +0000
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-13 12:57 +0200
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-11 14:27 -0500
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 22:03 +0200
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-11 15:56 -0500
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 11:30 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 23:34 +0100
Re: software disenchantment Keith Thompson <kst-u@mib.org> - 2018-10-11 16:24 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 01:46 +0100
Re: software disenchantment Keith Thompson <kst-u@mib.org> - 2018-10-11 18:58 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-12 08:50 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 11:12 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 12:55 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 12:10 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 13:29 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 13:06 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 14:30 +0200
Re: software disenchantment James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-12 08:53 -0400
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 15:11 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 13:55 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 15:13 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 16:10 +0100
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 15:22 +0000
Re: software disenchantment Keith Thompson <kst-u@mib.org> - 2018-10-12 09:12 -0700
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-13 13:00 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-13 12:52 +0100
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-14 08:44 +1300
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-13 21:03 +0100
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-14 10:13 +1300
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-13 23:02 +0100
Re: software disenchantment Keith Thompson <kst-u@mib.org> - 2018-10-13 16:47 -0700
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-14 01:05 +0100
Re: software disenchantment David Kleinecke <dkleinecke@gmail.com> - 2018-10-13 18:12 -0700
Re: software disenchantment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-14 03:05 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-14 20:14 +0200
Re: software disenchantment Thiago Adams <thiago.adams@gmail.com> - 2018-10-14 11:25 -0700
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 13:17 +0000
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 13:16 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 14:36 +0100
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 14:25 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-12 15:55 +0100
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 15:22 +0000
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-12 08:26 -0700
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-12 15:51 +0000
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-13 13:06 +0200
Re: software disenchantment Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-15 19:30 +0000
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 12:39 +0200
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-12 08:44 +0200
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 13:01 +0200
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 20:41 +0200
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 20:02 +0100
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 22:13 +0200
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-11 13:03 -0500
Re: software disenchantment "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-11 11:33 -0700
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 21:04 +0200
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-11 20:15 -0500
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-12 13:17 +0200
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 13:10 +0000
Re: software disenchantment BGB <cr88192@hotmail.com> - 2018-10-10 19:22 -0500
Re: software disenchantment David Brown <david.brown@hesbynett.no> - 2018-10-11 10:58 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 02:37 -0700
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 12:06 +0200
Re: software disenchantment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 04:00 -0700
Re: software disenchantment Cecil Bayona <cbayona@cbayona.com> - 2018-10-11 13:03 -0500
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 19:36 +0100
Re: software disenchantment Cecil Bayona <cbayona@cbayona.com> - 2018-10-11 15:37 -0500
Re: software disenchantment Thiago Adams <thiago.adams@gmail.com> - 2018-10-10 14:01 -0700
Re: software disenchantment Ian Collins <ian-news@hotmail.com> - 2018-10-11 09:02 +1300
Re: software disenchantment Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-10 19:11 +0000
Re: software disenchantment David Kleinecke <dkleinecke@gmail.com> - 2018-10-10 13:08 -0700
Re: software disenchantment Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-11 14:52 +0000
Re: software disenchantment scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 14:58 +0000
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-11 17:19 +0200
Re: software disenchantment Dan Purgert <dan@djph.net> - 2018-10-12 09:49 +0000
Re: software disenchantment Wouter Verhelst <w@uter.be> - 2018-10-13 09:30 +0200
Re: software disenchantment Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-15 08:53 +0000
Re: software disenchantment Dan Purgert <dan@djph.net> - 2018-10-15 09:44 +0000
Re: software disenchantment Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2018-10-10 13:36 +0000
Re: software disenchantment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-10-10 13:51 -0700
Re: software disenchantment nobody@example.org (Scott) - 2018-10-11 01:53 +0000
Re: software disenchantment Dan Purgert <dan@djph.net> - 2018-10-11 10:20 +0000
Re: software disenchantment Bart <bc@freeuk.com> - 2018-10-11 12:53 +0100
Re: software disenchantment "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-10-11 23:18 -0700
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-12 13:17 +0200 |
| Message-ID | <pppvt1$lsh$1@dont-email.me> |
| In reply to | #136704 |
On 12/10/18 03:15, BGB wrote: > On 10/11/2018 2:04 PM, David Brown wrote: >> On 11/10/18 20:03, BGB wrote: <snip> >>> One drawback IMO with GCC is that it tries to do too much with a >>> single compiler, leading it to be quite big and unwieldy. >>> >>> Several smaller and more specialized compilers could possibly better >>> address some things, with the main GCC mostly focusing on PC-like >>> targets; probably with other compilers toolchains for various classes >>> of embedded and microcontroller targets. >>> >> >> gcc /does/ focus on a certain class of processor - what might be >> termed "C friendly" processors. This covers a large number of >> devices, but misses many classes entirely - DSP's, 8-bit accumulator >> processors, anything with CHAR_BIT != 8 or signed integers that are >> not two's complement. >> > > I was meaning if, say, it focused mostly on x86 and ARM and similar > using ELF and maybe PE/COFF and MachO as output formats. Where should it draw the line? Should it just throw out existing support for other processors? Should people running Linux on MIPS or PPC start using a different compiler? There are many parts of the gcc source that are specific to certain target processors. When you configure a gcc build for a target, only the files and code sections relevant to that target are included in the build. A gcc binary is not capable of building binaries for more than one target family. So on my system I have a half different gcc executables, each "focused" on a different processor architecture or perhaps a different target OS. (Actually, I have many more, that are different versions of gcc for the same target.) > > In this case, most of the embedded cross compilers could be done via > forks or by other more specialized compilers; it doesn't seem like that > much would be lost as which combination of features exist and the > quality (or sanity) of the generated code already varies a bit from one > target to another. A /vast/ amount would be lost. I have long experience of gcc for embedded systems of all sorts - including some that have been maintained as out-of-tree patches rather than being mainline gcc targets. It is /hugely/ better for users that the targets are all together in the mainline gcc - that keeps them going, keeps them updated, and gives them the benefits of new features in the compiler. Compilers for "minor" targets - such as the AVR - benefit from all the improvements to the middle-end optimisations, the front-end language updates and warnings, etc. There are few developers working on the AVR port - they handle support for new chips, peephole optimisations, and other backend issues. Meanwhile, the avr-gcc compiler as a whole gets link-time optimisation, function cloning, partial inlining, C++17 support, -Wmisleading-indentation warnings, and all the other improvements that gcc has got over the past few years. > Just because it is gcc doesn't mean it generates good > code (or, for that matter, that trying to build a cross compiler for an > obscure target wont just result in a mess of build errors), if it is for > a target that isn't really being maintained. Of course. But maintenance of a target within gcc is far less work than maintenance of an independent compiler, or even an out-of-tree gcc port. As I say, I've used such ports - they invariably stagnate as the developers can't keep up with the effort of keeping synchronised with the mainline. > > It doesn't seem like one would really lose all that much apart from the > "brand familiarity" of it being gcc. > I can understand why it might seem like that, looking from the outside, but you are wrong.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-10-11 13:10 +0000 |
| Message-ID | <0ZHvD.102470$9O2.15978@fx03.iad> |
| In reply to | #136615 |
David Brown <david.brown@hesbynett.no> writes: >On 11/10/18 00:28, Bart wrote: >(And I don't care if your compiler can chew through a gazillion lines >per second - it won't do what I need, so its speed is irrelevant.) > Hear! Hear!
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2018-10-10 19:22 -0500 |
| Message-ID | <ppm52u$r17$1@news.albasani.net> |
| In reply to | #136588 |
On 10/10/2018 5:16 PM, Bart wrote: > On 10/10/2018 23:01, Ian Collins wrote: >> On 11/10/18 10:54, Bart wrote: > >>> And compiling from scratch is preferable to incremental compile which is >>> subject to conditions. So new ways of streamlining the process will >>> always be welcome. >> >> No, compiling from scratch isn't preferable to incremental builds. > > Even if both took the same amount of time? (Or both were fast enough to > be insignificant.) > > (My latest tools (not for C), /only/ compile from scratch. It means I > can make any change anywhere, and know it will taken into account > throughout the project, without incurring any sort of build penalty. > > Build time for my largest project, of 50K lines, can be 0.25 seconds. On > one core.) Hmm, my C compiler takes ~ 3s for 70 kLOC, and ~ 5s for 150 kLOC. For the same code and C library (but building for SH4 or ARM), GCC takes 20s and 35s (building translation units individually). I haven't thrown much bigger at it (the next step up size-wise would be trying to use it to build my "BGBTech2 engine" project, which is ~ 300 kLOC, *). Though my BJX2 emulator (which tries to be more-or-less cycle-accurate for a RISC-style scalar core running at 100MHz) would be nowhere near fast enough to make it usable, but it would at least fit within the RAM limit (256MB; a 128 block draw-distance needs ~ 160MB and a 96MB draw-distance needs ~ 100MB). *: BGBTech2 is basically a crappy Minecraft clone, and is mostly usable via a software renderer on a laptop with a 2.1GHz Celeron (the laptop also has an Intel GMA, but it kinda sucks and for whatever recently has been acting up and is seemingly no longer rendering textures in OpenGL). But, quick estimates don't look terribly promising for much under 1GHz, much less 100MHz (this can run Doom pretty well, but I need to boost to around 200-300 before Quake is all that playable). I guess the first order of business though would be if my C compiler can compile it without falling on its face...
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-11 10:58 +0200 |
| Message-ID | <ppn3b1$vqf$1@dont-email.me> |
| In reply to | #136588 |
On 11/10/18 00:16, Bart wrote: > On 10/10/2018 23:01, Ian Collins wrote: >> On 11/10/18 10:54, Bart wrote: > >>> And compiling from scratch is preferable to incremental compile which is >>> subject to conditions. So new ways of streamlining the process will >>> always be welcome. >> >> No, compiling from scratch isn't preferable to incremental builds. > > Even if both took the same amount of time? (Or both were fast enough to > be insignificant.) If they take the same amount of time, then it makes no difference, and neither is preferable. The only reason compiling from scratch would be preferable is if it gave different and better results in the end, or if your incremental build did not always rebuild everything that should have been rebuilt. If that's the case, then your incremental build setup is broken. So the answer is to fix the incremental build setup.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-10-11 02:37 -0700 |
| Message-ID | <5883bc90-a2f3-4083-ac83-372bcde265a8@googlegroups.com> |
| In reply to | #136609 |
On Thursday, October 11, 2018 at 9:58:18 AM UTC+1, David Brown wrote: > > The only reason compiling from scratch would be preferable is if it gave > different and better results in the end, or if your incremental build > did not always rebuild everything that should have been rebuilt. If > that's the case, then your incremental build setup is broken. > > So the answer is to fix the incremental build setup. > Things like incremental build work really well. Until something goes wrong. Then it's a nightmare to try to troubleshoot.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-10-11 12:06 +0200 |
| Message-ID | <htj39f-fgd.ln1@gangtai.home.grep.be> |
| In reply to | #136614 |
On 11/10/18 11:37, Malcolm McLean wrote: > On Thursday, October 11, 2018 at 9:58:18 AM UTC+1, David Brown wrote: >> >> The only reason compiling from scratch would be preferable is if it gave >> different and better results in the end, or if your incremental build >> did not always rebuild everything that should have been rebuilt. If >> that's the case, then your incremental build setup is broken. >> >> So the answer is to fix the incremental build setup. >> > Things like incremental build work really well. Until something goes wrong. > Then it's a nightmare to try to troubleshoot. That's true for all software, and is not specific to bugs in incremental builds.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-10-11 04:00 -0700 |
| Message-ID | <b226d42b-bca1-4822-8cbc-6f18ef987e37@googlegroups.com> |
| In reply to | #136617 |
On Thursday, October 11, 2018 at 11:09:54 AM UTC+1, Wouter Verhelst wrote: > On 11/10/18 11:37, Malcolm McLean wrote: > > On Thursday, October 11, 2018 at 9:58:18 AM UTC+1, David Brown wrote: > >> > >> The only reason compiling from scratch would be preferable is if it gave > >> different and better results in the end, or if your incremental build > >> did not always rebuild everything that should have been rebuilt. If > >> that's the case, then your incremental build setup is broken. > >> > >> So the answer is to fix the incremental build setup. > >> > > Things like incremental build work really well. Until something goes wrong. > > Then it's a nightmare to try to troubleshoot. > > That's true for all software, and is not specific to bugs in incremental > builds. > The more complicated it is the more likely it is to go wrong, and the harder it is to fix when it does go wrong. So there's an acronym, KISS.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2018-10-11 13:03 -0500 |
| Message-ID | <ppo39p$u4l$1@dont-email.me> |
| In reply to | #136580 |
On 10/10/2018 4:54 PM, Bart wrote: > On 10/10/2018 21:27, Scott Lurndal wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >>> On Wednesday, October 10, 2018 at 4:06:17 PM UTC-4, Ian Collins wrote: >>>> On 11/10/18 08:53, Rick C. Hodgin wrote: >>>>> On 10/10/2018 3:22 PM, BGB wrote: >>>>>> On 10/10/2018 1:04 PM, Thiago Adams wrote: >>>>>>> The solution is pre-compiled headers. We still have the "source" >>>>>>> and the pre-compiled headers can optimize the parser. >>>>> >>>>> Pre-compiled headers don't always get you there. You can have >>>>> pre-parsed headers, but even then if a #define comes into play >>>>> which re-defines something referenced somewhere, your pre- >>>>> compiled header will be invalid and may require a full repars- >>>>> ing anyway. >>>> >>>> Which is why compilers usually require the precompiled headers header >>>> include to be the first item in a compilation unit. >> >>> Having the ability to parse out every source files, and then to >>> be able to do a hard lookup on individual changes as source code >>> is being edited in real-time ... it's far more desirable because >>> it addresses the entire code base with a processing time spread >>> out over normal developer IDE use. >> >> But it's a non-existent problem. >> >> The project I work on at the moment as per the sloccount utility: >> >> Totals grouped by language (dominant language first): >> ansic: 2160423 (72.79%) >> cpp: 452648 (15.25%) >> python: 317663 (10.70%) >> asm: 34952 (1.18%) >> perl: 1103 (0.04%) >> sh: 1093 (0.04%) >> >> Total Physical Source Lines of Code (SLOC) = 2,967,882 >> >> full build timing: >> >> real 2m49.10s >> user 17m0.46s >> sys 1m50.75s >> >> Less than three minutes[*] for a two million line compile is in the >> noise. And >> incremental compiles (the norm for a developer) are basically >> instananeous (recompile one or two files and relink). > > What counts as 'instant' here? My threshold is about 0.2 seconds, above > which any delay becomes increasingly annoying. > >> I don't see that spending any time at all with respect to optimization >> of handling header files would have any real world benefit (note that >> there >> are over a million lines of header files in the above project). >> >> [*] the more observent may notice that it took about 19 minutes of >> CPU time, but less than three minutes of wall time. Parallelism is your >> friend. > > Do you have a figure for the number of C source lines that are actually > processed? (Due to repeatedly processing the same headers etc.) What > part does file caching play here? > > Working only with a 2.6Mloc of cached C/C++ sources and the 19 minutes > (ignoring the other stuff; does the Python need to be compiled?) that > gives a throughput of under 2.5 Kloc per second, per core. > > I think Tiny C can probably do at least 100 times that. And, unless the > code is a single monolithic source file, can also be employed on > multiple cores. That would give the possibility of a cold compile, for > the 2M lines of C sources, of a few seconds. > > What I'm saying is that 3 minutes' build time, even 3M lines of code, is > still three minutes. Too long to have to wait for anything without > finding something else to do. And by the time you get back to it, it > will be a lot more than 3 minutes. > > And compiling from scratch is preferable to incremental compile which is > subject to conditions. So new ways of streamlining the process will > always be welcome. > > I'm new here and see you mention Tiny C, is there a web site with more information? Google has not been very productive in finding information as there are a multitude of Tiny C compilers from the 80's and 90's. The main hit I get is TCC Tiny C Compiler is that it or is it something else? Thanks -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-11 19:36 +0100 |
| Message-ID | <PKMvD.9043$9M1.1792@fx23.am4> |
| In reply to | #136676 |
On 11/10/2018 19:03, Cecil Bayona wrote: > On 10/10/2018 4:54 PM, Bart wrote: > I'm new here and see you mention Tiny C, is there a web site with more > information? Google has not been very productive in finding information > as there are a multitude of Tiny C compilers from the 80's and 90's. The > main hit I get is TCC Tiny C Compiler is that it or is it something else? Try this for a download: http://download.savannah.gnu.org/releases/tinycc/ 0.9.27 is the most recent version after being stuck at 0.9.26 for several years. It's quite a capable C99 compiler, and is not a toy (as I once thought, and many here still think). That page is linked to from here: https://bellard.org/tcc/ Search also for 'tiny c github'. -- bart
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2018-10-11 15:37 -0500 |
| Message-ID | <ppoc9r$rb9$1@dont-email.me> |
| In reply to | #136684 |
On 10/11/2018 1:36 PM, Bart wrote: > On 11/10/2018 19:03, Cecil Bayona wrote: >> On 10/10/2018 4:54 PM, Bart wrote: > >> I'm new here and see you mention Tiny C, is there a web site with more >> information? Google has not been very productive in finding >> information as there are a multitude of Tiny C compilers from the 80's >> and 90's. The main hit I get is TCC Tiny C Compiler is that it or is >> it something else? > > > Try this for a download: > > http://download.savannah.gnu.org/releases/tinycc/ > > 0.9.27 is the most recent version after being stuck at 0.9.26 for > several years. It's quite a capable C99 compiler, and is not a toy (as I > once thought, and many here still think). > > That page is linked to from here: https://bellard.org/tcc/ > > Search also for 'tiny c github'. > > Thanks, so it's TCC, I have that version installed on several PCs, and I'm quite happy with it so far. I'm not a "professional" and quit using C many years ago, I used to use it a lot in the 80's and 90's, but I'm starting to get back into it. I have a small project that I been working on and I wanted it to be somewhat portable to Windows and Linux so I been playing with various C compilers and to my surprise my favorite after trying several C compilers is TCC. The project is very small and consist of one C file. I originally worked on it on msvc but that is a huge beast and I didn't want to have to install it everywhere so I started looking at various C compilers. TCC compiles it to a tiny 19KB executable but when I tried various other "optimizing" compilers they compile an executable 3X to 4X the size so I reverted back to using TCC as the main development tool, being instantaneous at compiling sure is a pleasant benefit. Probably GCC and Clang generate better code but I'm no fan of those bloated packages. I agree with the main thrust of this thread that software development has for sure taken a wrong turn which has negated a lot of the benefits of faster CPUs and larger storage by creating bigger and more bloated software. I'm retired due to health issues which many doctors have not been able to figure out what is going on so I play with my computers a lot and wanted to write some software that I'm interested it but wanted a measure of portability so I restarted using C again as it can be quite portable if one is careful. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-10-10 14:01 -0700 |
| Message-ID | <070624d3-339e-41af-91d5-7d7c9fc1bfd4@googlegroups.com> |
| In reply to | #136569 |
On Wednesday, October 10, 2018 at 4:21:58 PM UTC-3, BGB wrote: > On 10/10/2018 1:04 PM, Thiago Adams wrote: > > On Wednesday, October 10, 2018 at 2:45:28 PM UTC-3, BGB wrote: > >> On 10/10/2018 7:49 AM, Malcolm McLean wrote: > >>> On Wednesday, October 10, 2018 at 11:39:11 AM UTC+1, Bart wrote: > >>>> On 10/10/2018 11:28, Bart wrote: > >>>> > >>>>> Then you /are/ looking at a cut-down C, but you wouldn't cut down > >>>>> essentials such as for and while loops. You would get rid of most of the > >>>>> processor > >>>> > >>>> I mean most of the preprocessor. > >>>> > >>>> Getting rid of the processor would be rather drastic. > >>>> > >>> We need to get rid of the "sticky" rule with C. The rule that means you have > >>> to pull in a system header which includes dozens of other headers, just > >>> because you need the symbol "DWORD" for some reason. > >>> How to do that isn't obvious. > >>> > >> > >> One "possible" option is partly replacing header inclusion with > >> database-like metadata, but pulling this off effectively without > >> breaking things in the language is harder. > > > > I like the #ifdef mechanism. > > > > In C++ modules or in your database-like how do you deal > > with different compilation settings? > > We would need many metatada for each combination of settings. > > > > The solution is pre-compiled headers. We still have the "source" > > and the pre-compiled headers can optimize the parser. > > > > The header source would still exist in such a database, just it wouldn't > be used directly by the "#include" mechanism when including a "header" > which exists within this database. > > In a previous attempt, I had split up ifdef's into two different groups > (depending on the define): those which were still handled during > preprocessing, and those which were "delayed" until a later stage in the > compiler (effectively, they were translated to a different syntax). All > of the relevant branches would then be compiled just with attributes > encoding which defines a given declaration or code-block depends on, ... > With N/A contents being pruned away in the compiler's backend). > > The problem was that this imposed constraints on how this feature could > be used (*) and still didn't adequately address some issues I had > initially set out to "solve" (like a single binary working with > different C library implementations or OS APIs; at best case the C > library would need a wrapper or for the compiler to provide its own C > library and similar). > > > *: For example, everything within the block had to be "syntactically > valid" on its own, couldn't be used for macro expansion, required types > to exist regardless of whether or not the block was used, ... C++ templates have a similar problem to be syntactically valid, sometimes it is not possible to understand that a identifier is a type then sometimes the keyword typename is required for disambiguation. C++ has 'constexpr if' that works in this way. Also, if you depends on something like macro from some include from the platform and you don't have the file then is impossible to parse the "#else parts". Having a full parsed module means that we would have to parse the 'header' including all headers from all platforms let's say windows, linux etc.. I don't like C++ modules and I think #include and #ifdef are useful. The best way still one header file and one implementation file and it will work in many platforms. Another field of improvement would be move the preprocessor for the parser phase. I have suggested this on the past and I still think it is possible.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-10-11 09:02 +1300 |
| Message-ID | <g2746sFjb2cU3@mid.individual.net> |
| In reply to | #136505 |
On 10/10/18 09:22, Bart wrote: > On 09/10/2018 19:54, David Kleinecke wrote: >> On Tuesday, October 9, 2018 at 11:20:38 AM UTC-7, anti...@math.uni.wroc.pl wrote: >>> Bart <bc@freeuk.com> wrote: >>>> I saw this posted in alt.folklore.computers: >>>> >>>> http://tonsky.me/blog/disenchantment/ >>>> >>>> Interesting read that sums up many of my own thoughts and experiences. >>>> >>>> Although the reaction in that group wasn't very sympathetic. >>>> >>> >>> Well, the guy wrote some right things, but in general it is >>> quite shalow. To be short: >>> >>> - modern programs do much more than DOS ere program, even if >>> they look like "equivalent" from naive user point of view >> >> There is often a question about whether that "more" >> is of any real value. >> . >>> - modern programs frequetnly work with much larger amount of >>> data than old program >> >> A valid reason for growth in size but not for >> growth in complexity. >> >>> - consequently there are good technical reasons that modern >>> programs are larger than older ones >> >>> - users get what they pay for. And they complain about slow >>> programs but quite frequently choose slow program instead >>> of faster ones (for example because slow program has some >>> feature and faster one does not) >> >> Usually no alternatives are offered. >> >> Perhaps the only justification for seeking simplicity >> is esthetic. I'm retired - I can afford to be esthetic. >> I agree that people working for a living should do >> what they need to do. > > No, there are other advantages too. Actually I can't think of too many > downsides of something being small and simple: There is one: - It doesn't do what the customer wants. The code base (really bases, there are multiple languages) is large and complex, why? Because the problem domain is large and complex. The mathematics is complex, the machine control is complex, the peripheral devices we manage are complex, the 3D operator UI is complex and so on. With "embedded" projects such as ours we can't afford unnecessary complexity, we have fixed processing assets that we have to support for years. Every clock cycle counts. But that doesn't mean we don't have to solve complex problems. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-10-10 19:11 +0000 |
| Message-ID | <slrnprsjn7.f78.grahn+nntp@frailea.sa.invalid> |
| In reply to | #136498 |
On Tue, 2018-10-09, David Kleinecke wrote: > On Tuesday, October 9, 2018 at 11:20:38 AM UTC-7, anti...@math.uni.wroc.pl wrote: ... >> - modern programs frequetnly work with much larger amount of >> data than old program > > A valid reason for growth in size but not for > growth in complexity. I don't see a valid reason for growth in size, either. (Except in extreme cases, such as Unix sort(1) keeping temporary files so it can sort N bytes of data without using N bytes of heap.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2018-10-10 13:08 -0700 |
| Message-ID | <47a2bd55-59bd-499b-948c-95bba9475e9a@googlegroups.com> |
| In reply to | #136568 |
On Wednesday, October 10, 2018 at 12:11:47 PM UTC-7, Jorgen Grahn wrote: > On Tue, 2018-10-09, David Kleinecke wrote: > > On Tuesday, October 9, 2018 at 11:20:38 AM UTC-7, anti...@math.uni.wroc.pl wrote: > ... > >> - modern programs frequetnly work with much larger amount of > >> data than old program > > > > A valid reason for growth in size but not for > > growth in complexity. > > I don't see a valid reason for growth in size, either. For example screen size. Many more pixels nowadays.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-10-11 14:52 +0000 |
| Message-ID | <slrnpruosu.f78.grahn+nntp@frailea.sa.invalid> |
| In reply to | #136574 |
On Wed, 2018-10-10, David Kleinecke wrote: > On Wednesday, October 10, 2018 at 12:11:47 PM UTC-7, Jorgen Grahn wrote: >> On Tue, 2018-10-09, David Kleinecke wrote: >> > On Tuesday, October 9, 2018 at 11:20:38 AM UTC-7, anti...@math.uni.wroc.pl wrote: >> ... >> >> - modern programs frequetnly work with much larger amount of >> >> data than old program >> > >> > A valid reason for growth in size but not for >> > growth in complexity. >> >> I don't see a valid reason for growth in size, either. > > For example screen size. Many more pixels nowadays. But surely you don't need more code to handle more pixels? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-10-11 14:58 +0000 |
| Message-ID | <LyJvD.139981$8r2.35993@fx34.iad> |
| In reply to | #136643 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >On Wed, 2018-10-10, David Kleinecke wrote: >> On Wednesday, October 10, 2018 at 12:11:47 PM UTC-7, Jorgen Grahn wrote: >>> On Tue, 2018-10-09, David Kleinecke wrote: >>> > On Tuesday, October 9, 2018 at 11:20:38 AM UTC-7, anti...@math.uni.wroc.pl wrote: >>> ... >>> >> - modern programs frequetnly work with much larger amount of >>> >> data than old program >>> > >>> > A valid reason for growth in size but not for >>> > growth in complexity. >>> >>> I don't see a valid reason for growth in size, either. >> >> For example screen size. Many more pixels nowadays. > >But surely you don't need more code to handle more pixels? > One may need to change the algorithm for efficiency, handling 640x480 pixels (at maybe 8-bit per) is quite different from handling 3840x2048 at 32-bits per plus an alpha channel.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-10-11 17:19 +0200 |
| Message-ID | <l9649f-n27.ln1@gangtai.home.grep.be> |
| In reply to | #136643 |
On 11/10/18 16:52, Jorgen Grahn wrote: > On Wed, 2018-10-10, David Kleinecke wrote: >> On Wednesday, October 10, 2018 at 12:11:47 PM UTC-7, Jorgen Grahn wrote: >>> On Tue, 2018-10-09, David Kleinecke wrote: >>>> On Tuesday, October 9, 2018 at 11:20:38 AM UTC-7, anti...@math.uni.wroc.pl wrote: >>> ... >>>>> - modern programs frequetnly work with much larger amount of >>>>> data than old program >>>> >>>> A valid reason for growth in size but not for >>>> growth in complexity. >>> >>> I don't see a valid reason for growth in size, either. >> >> For example screen size. Many more pixels nowadays. > > But surely you don't need more code to handle more pixels? Not necessarily. If you want to include an image to be shown in the UI, though, it will need more pixels. It's fine to have a pixelated "floppy disk" icon on a 640x480x16 VGA display. It's not so fine to have that on a 4K UHD display; users expect more detailed icons there. A 16-color, 16-by-16 image will require less space than a 24-bit-plus-alpha, 512-by-512 image, for obvious reasons. Obviously this isn't just about toolbar icons, there are other things that may need to be shown, too. You get the idea.
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2018-10-12 09:49 +0000 |
| Message-ID | <slrnps0rh9.o3q.dan@xps-linux.djph.net> |
| In reply to | #136653 |
Wouter Verhelst wrote: > On 11/10/18 16:52, Jorgen Grahn wrote: >> On Wed, 2018-10-10, David Kleinecke wrote: >>> [...] >>> For example screen size. Many more pixels nowadays. >> >> But surely you don't need more code to handle more pixels? > > Not necessarily. If you want to include an image to be shown in the UI, > though, it will need more pixels. > > It's fine to have a pixelated "floppy disk" icon on a 640x480x16 VGA > display. It's not so fine to have that on a 4K UHD display; users expect > more detailed icons there. Right, but I think Jorgen's point is that "load_image()" isn't going to suddenly need to balloon to 500B to support a 4K display, when it was only 100B previously. There's no argument that OTHER things take greater space, because we demand greater eye-candy (or sound fidelity, or..) -- although, this doesn't account for our greater ability to compress these datatypes either. -- |_|O|_| Registered Linux user #585947 |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-10-13 09:30 +0200 |
| Message-ID | <8hj89f-eo6.ln1@gangtai.home.grep.be> |
| In reply to | #136712 |
On 12/10/18 11:49, Dan Purgert wrote: > Wouter Verhelst wrote: >> On 11/10/18 16:52, Jorgen Grahn wrote: >>> On Wed, 2018-10-10, David Kleinecke wrote: >>>> [...] >>>> For example screen size. Many more pixels nowadays. >>> >>> But surely you don't need more code to handle more pixels? >> >> Not necessarily. If you want to include an image to be shown in the UI, >> though, it will need more pixels. >> >> It's fine to have a pixelated "floppy disk" icon on a 640x480x16 VGA >> display. It's not so fine to have that on a 4K UHD display; users expect >> more detailed icons there. > > Right, but I think Jorgen's point is that "load_image()" isn't going > to suddenly need to balloon to 500B to support a 4K display, when it was > only 100B previously. I didn't get that impression. I saw people look at disk usage and go "oh, golly, there's so much more stuff here", without distinguishing between code and data. I think that the data part of an OS is a much larger percentage of it these days than it was 20 years ago, and that that is a large part of why you can't install any modern operating system on any disk sizes that were sold 20 years ago.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-10-15 08:53 +0000 |
| Message-ID | <slrnps8lc9.f78.grahn+nntp@frailea.sa.invalid> |
| In reply to | #136743 |
On Sat, 2018-10-13, Wouter Verhelst wrote: > On 12/10/18 11:49, Dan Purgert wrote: >> Wouter Verhelst wrote: >>> On 11/10/18 16:52, Jorgen Grahn wrote: >>>> On Wed, 2018-10-10, David Kleinecke wrote: >>>>> [...] >>>>> For example screen size. Many more pixels nowadays. >>>> >>>> But surely you don't need more code to handle more pixels? >>> >>> Not necessarily. If you want to include an image to be shown in the UI, >>> though, it will need more pixels. >>> >>> It's fine to have a pixelated "floppy disk" icon on a 640x480x16 VGA >>> display. It's not so fine to have that on a 4K UHD display; users expect >>> more detailed icons there. >> >> Right, but I think Jorgen's point is that "load_image()" isn't going >> to suddenly need to balloon to 500B to support a 4K display, when it was >> only 100B previously. > > I didn't get that impression. My point was exactly what Dan writes above. > I saw people look at disk usage and go > "oh, golly, there's so much more stuff here", without distinguishing > between code and data. People do that, but I reacted to a statement upthread about code only. > I think that the data part of an OS is a much larger percentage of it > these days than it was 20 years ago, and that that is a large part of > why you can't install any modern operating system on any disk sizes that > were sold 20 years ago. This would be a nice subject for an investigation and maybe a paper. Pick an OS installation. Pick 100 bytes at random in the non-user, non-cache data. Go through them and classify them according to purpose: - essential part of an essential utility - dead code - documentation - pixel in an unused icon theme for an unused desktop environment - etc /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web