Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #126536 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2018-02-10 12:41 -0800 |
| Last post | 2018-02-12 23:21 +0100 |
| Articles | 20 on this page of 103 — 26 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: C2 Aims to Modernize the C Language David Kleinecke <dkleinecke@gmail.com> - 2018-02-10 12:41 -0800
Re: C2 Aims to Modernize the C Language Chad <cdalten@gmail.com> - 2018-02-10 13:38 -0800
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 00:32 +0100
Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-10 17:23 -0800
Re: C2 Aims to Modernize the C Language Anton Shepelev <anton.txt@gmail.com> - 2018-02-11 13:53 +0300
Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-11 13:26 +0000
Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-11 13:04 -0800
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-11 01:34 +0000
Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-10 17:42 -0800
Re: C2 Aims to Modernize the C Language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-02-10 17:50 -0800
Re: C2 Aims to Modernize the C Language fir <profesor.fir@gmail.com> - 2018-02-14 11:54 -0800
Re: C2 Aims to Modernize the C Language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-02-14 12:14 -0800
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 04:48 +0100
Re: C2 Aims to Modernize the C Language Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-10 22:35 -0700
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 13:25 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-11 11:18 +0000
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-11 21:57 +0000
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-12 14:10 +1300
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 11:11 +0000
Re: C2 Aims to Modernize the C Language Reinhardt Behm <rbehm@hushmail.com> - 2018-02-12 20:33 +0800
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 13:43 +0000
Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-12 06:05 -0800
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-13 07:13 +1300
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 01:17 +0000
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 09:55 +0100
Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-13 12:28 -0600
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-14 11:36 +1300
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 00:59 +0000
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-14 15:19 +1300
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 14:07 +0000
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-03-06 15:46 +0000
Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-13 20:31 -0600
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-14 15:42 +1300
Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-14 01:13 -0600
Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-21 15:13 +0000
Re: C2 Aims to Modernize the C Language supercat@casperkitty.com - 2018-02-21 08:43 -0800
Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-21 19:21 +0000
Re: C2 Aims to Modernize the C Language Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 12:25 -0600
Re: C2 Aims to Modernize the C Language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-21 19:28 +0000
Re: C2 Aims to Modernize the C Language Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 18:29 -0600
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-22 08:33 +1300
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 14:48 +0000
Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-14 11:54 -0600
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 20:41 +0000
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 00:00 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 00:59 +0000
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 12:29 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 12:18 +0000
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-12 15:27 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 15:19 +0000
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-12 16:49 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 17:16 +0000
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-13 07:30 +1300
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-12 22:37 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 22:15 +0000
Re: C2 Aims to Modernize the C Language Ian Collins <ian-news@hotmail.com> - 2018-02-13 17:05 +1300
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 11:11 +0000
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 10:32 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 11:10 +0000
Re: C2 Aims to Modernize the C Language gordonb.5itdn@burditt.org (Gordon Burditt) - 2018-02-14 12:57 -0600
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-14 20:29 +0000
Re: C2 Aims to Modernize the C Language gordonb.nrdl0@burditt.org (Gordon Burditt) - 2018-02-14 19:22 -0600
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-15 14:59 +0000
Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 04:00 -0800
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 14:46 +0100
Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 08:49 -0800
Re: C2 Aims to Modernize the C Language Thiago Adams <thiago.adams@gmail.com> - 2018-02-13 09:52 -0800
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-13 13:47 +0100
Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 05:11 -0800
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 14:49 +0100
Re: C2 Aims to Modernize the C Language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-13 21:52 +0800
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 14:45 +0000
Re: C2 Aims to Modernize the C Language Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-13 07:45 -0800
Re: C2 Aims to Modernize the C Language Chad <cdalten@gmail.com> - 2018-02-13 05:35 -0800
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 13:21 +0000
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 13:24 +0000
Re: C2 Aims to Modernize the C Language Egor <egor@ruby.local> - 2018-02-13 13:14 +0200
Re: C2 Aims to Modernize the C Language already5chosen@yahoo.com - 2018-02-13 04:38 -0800
Re: C2 Aims to Modernize the C Language Egor <egor@ruby.local> - 2018-02-14 13:25 +0200
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-13 13:39 +0000
Re: C2 Aims to Modernize the C Language Egor <egor@ruby.local> - 2018-02-14 13:42 +0200
Re: C2 Aims to Modernize the C Language supercat@casperkitty.com - 2018-02-15 13:17 -0800
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 04:41 +0100
Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 17:25 +0100
Re: C2 Aims to Modernize the C Language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-12 17:28 +0000
Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 21:01 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 17:51 +0000
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 19:28 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 20:02 +0000
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 23:32 +0100
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 10:42 +0100
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-13 13:26 +0100
Re: C2 Aims to Modernize the C Language Richard Damon <Richard@Damon-Family.org> - 2018-02-13 08:06 -0500
Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-13 15:16 +0100
Re: C2 Aims to Modernize the C Language David Brown <david.brown@hesbynett.no> - 2018-02-13 14:53 +0100
Re: C2 Aims to Modernize the C Language BGB <cr88192@hotmail.com> - 2018-02-13 15:22 -0600
Re: C2 Aims to Modernize the C Language Keith Thompson <kst-u@mib.org> - 2018-02-12 12:26 -0800
Re: C2 Aims to Modernize the C Language GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-12 23:45 +0100
Re: C2 Aims to Modernize the C Language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-02-12 15:52 -0800
Re: C2 Aims to Modernize the C Language Chad <cdalten@gmail.com> - 2018-02-12 17:13 -0800
Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 21:15 +0100
Re: C2 Aims to Modernize the C Language bartc <bc@freeuk.com> - 2018-02-12 21:42 +0000
Re: C2 Aims to Modernize the C Language Manfred <noname@invalid.add> - 2018-02-12 23:21 +0100
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-12 13:43 +0000 |
| Message-ID | <PRggC.820$tD1.709@fx33.am4> |
| In reply to | #126595 |
On 12/02/2018 12:33, Reinhardt Behm wrote: > AT Monday 12 February 2018 19:11, bartc wrote: > >> (Presumably, to write the Windows installation details, it must have >> been tested on Windows, so why didn't they make the resulting .exe >> available?) > > They did it as favor for you, so that you have something to complain about. I'm stating facts. This project is too complicated for me to build (it's not really install) on Windows. But it is typical of applications that originate from Unix. Here's how I do it: http://www.bcas.freeuk.com/mcc.exe Download this one file, save it anywhere, and run it. It will give instructions. (An old version, this compiles .c files to .asm files.) Want to build from [pseudo-]source if you don't trust binaries? Try: http://www.bcas.freeuk.com/mcc64.c Instructions at the top of the file. See the difference? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-02-12 06:05 -0800 |
| Message-ID | <94cb74fa-cb02-4a2d-9906-b6a8a3531c11@googlegroups.com> |
| In reply to | #126596 |
On Monday, February 12, 2018 at 11:43:29 AM UTC-2, Bart wrote: > On 12/02/2018 12:33, Reinhardt Behm wrote: > > AT Monday 12 February 2018 19:11, bartc wrote: > > > >> (Presumably, to write the Windows installation details, it must have > >> been tested on Windows, so why didn't they make the resulting .exe > >> available?) > > > > They did it as favor for you, so that you have something to complain about. > > I'm stating facts. This project is too complicated for me to build (it's > not really install) on Windows. But it is typical of applications that > originate from Unix. > > Here's how I do it: > > http://www.bcas.freeuk.com/mcc.exe > > Download this one file, save it anywhere, and run it. It will give > instructions. (An old version, this compiles .c files to .asm files.) > > Want to build from [pseudo-]source if you don't trust binaries? Try: > > http://www.bcas.freeuk.com/mcc64.c > > Instructions at the top of the file. > > See the difference? > > -- I like small applications. This is not a complain about c2, but I appreciate auto contained C programs. My cprime tool is 390K.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-02-13 07:13 +1300 |
| Message-ID | <fee3psFm5eaU2@mid.individual.net> |
| In reply to | #126591 |
On 02/13/2018 12:11 AM, bartc wrote: > On 12/02/2018 01:10, Ian Collins wrote: >> On 02/12/2018 10:57 AM, bartc wrote: >>> On 11/02/2018 11:18, bartc wrote: >>> >>>> One of the C2 aims is specifically not to be more advanced, or do any >>>> more, just do what C does but in a more modern way. >>> >>> I've just looked at what is involved in trying out C2. >>> >>> All I need to install is the basic Cygwin along with make, cmake, gcc, >>> libncurses-dev, ncurses, Python, git and clang... >>> >>> It then says, 'C2 is based on LLVM 5.0 and some parts of Clang, so we >>> will need to build it first'. Presumably 'it' means LLVM. >>> >>> So it looks I'm not going to be trying out this language any time soon. >> >> Did you actually read the instructions? > > Did you? Yes, nice and simple. > The above is a direct quote from the Windows installation instructions > (https://github.com/c2lang/c2compiler/blob/master/INSTALL_WIN.md). > > It relies heavily on Unix tools (a massive dependency if using Windows) > and on LLVM (a massive subsystem). If you are building a compiler, why wouldn't you use a well respected opensource compiler infrastructure project? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-13 01:17 +0000 |
| Message-ID | <f0rgC.17825$w26.6707@fx47.am4> |
| In reply to | #126607 |
On 12/02/2018 18:13, Ian Collins wrote: > On 02/13/2018 12:11 AM, bartc wrote: >> Did you? > > Yes, nice and simple. You must have a perverse idea of what is simple. >> The above is a direct quote from the Windows installation instructions >> (https://github.com/c2lang/c2compiler/blob/master/INSTALL_WIN.md). >> >> It relies heavily on Unix tools (a massive dependency if using Windows) >> and on LLVM (a massive subsystem). > > If you are building a compiler, why wouldn't you use a well respected > opensource compiler infrastructure project? Because it's complicated? And out of proportion to the complexity of the language being processed, which looks simple. I looked at LLVM myself perhaps a decade ago. There was a lot of documentation about, some FORTY FOUR sets of it. I don't know what it's like now. My thing, as people might know from my posts, is managing to do stuff on a small scale, and keeping things small, simple and tidy where possible. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-13 09:55 +0100 |
| Message-ID | <p5u958$e9d$1@dont-email.me> |
| In reply to | #126630 |
On 13/02/18 02:17, bartc wrote: > On 12/02/2018 18:13, Ian Collins wrote: >> On 02/13/2018 12:11 AM, bartc wrote: > >>> Did you? >> >> Yes, nice and simple. > > You must have a perverse idea of what is simple. There is a set of instructions to follow. Follow these, and you should have the C2 compiler. I have not followed them myself (I am totally uninterested in having a C2 compiler - at least at this stage). Installing cygwin on Windows is not a difficult task, nor is installing these packages (you click them from the list in the cygwin installer). The instructions here are simple in that the list of requirements is short and complete - you don't have to think for yourself. And so on, through the installation. It will be a time-consuming job. But the instructions are all there - you don't need to figure things out. You don't need any familiarity with clang or llvm, or git, or cmake, or any of the tools involved. "Simple" does not mean "small", or "one step". > >>> The above is a direct quote from the Windows installation instructions >>> (https://github.com/c2lang/c2compiler/blob/master/INSTALL_WIN.md). >>> >>> It relies heavily on Unix tools (a massive dependency if using Windows) >>> and on LLVM (a massive subsystem). >> >> If you are building a compiler, why wouldn't you use a well respected >> opensource compiler infrastructure project? > > Because it's complicated? And out of proportion to the complexity of the > language being processed, which looks simple. If you are making a language that is a reasonable fit for llvm, then why not use it? Rather than spending months making a limited little code generator for a single processor on a single OS, you can get a big, powerful system for free, with vastly more features. Sure, it might take you a week to read through the documentation and play around with it - but it is a week, not months, and the result is far beyond what you would achieve in years. > > I looked at LLVM myself perhaps a decade ago. There was a lot of > documentation about, some FORTY FOUR sets of it. I don't know what it's > like now. > > My thing, as people might know from my posts, is managing to do stuff on > a small scale, and keeping things small, simple and tidy where possible. >
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2018-02-13 12:28 -0600 |
| Message-ID | <p5vanl$bl8$1@news.albasani.net> |
| In reply to | #126640 |
On 2/13/2018 2:55 AM, David Brown wrote:
> On 13/02/18 02:17, bartc wrote:
>> On 12/02/2018 18:13, Ian Collins wrote:
>>> On 02/13/2018 12:11 AM, bartc wrote:
>>
>>>> Did you?
>>>
>>> Yes, nice and simple.
>>
>> You must have a perverse idea of what is simple.
>
> There is a set of instructions to follow. Follow these, and you should
> have the C2 compiler. I have not followed them myself (I am totally
> uninterested in having a C2 compiler - at least at this stage).
> Installing cygwin on Windows is not a difficult task, nor is installing
> these packages (you click them from the list in the cygwin installer).
> The instructions here are simple in that the list of requirements is
> short and complete - you don't have to think for yourself.
>
> And so on, through the installation.
>
> It will be a time-consuming job. But the instructions are all there -
> you don't need to figure things out. You don't need any familiarity
> with clang or llvm, or git, or cmake, or any of the tools involved.
>
> "Simple" does not mean "small", or "one step".
>
>>
>>>> The above is a direct quote from the Windows installation instructions
>>>> (https://github.com/c2lang/c2compiler/blob/master/INSTALL_WIN.md).
>>>>
>>>> It relies heavily on Unix tools (a massive dependency if using Windows)
>>>> and on LLVM (a massive subsystem).
>>>
>>> If you are building a compiler, why wouldn't you use a well respected
>>> opensource compiler infrastructure project?
>>
>> Because it's complicated? And out of proportion to the complexity of the
>> language being processed, which looks simple.
>
> If you are making a language that is a reasonable fit for llvm, then why
> not use it? Rather than spending months making a limited little code
> generator for a single processor on a single OS, you can get a big,
> powerful system for free, with vastly more features. Sure, it might
> take you a week to read through the documentation and play around with
> it - but it is a week, not months, and the result is far beyond what you
> would achieve in years.
>
however, if in the nature of the project (say, targeting a
custom/experimental CPU arch), and one needs to rebuild LLVM multiple
times, then there is a problem... (or if even trying to build it once,
and ones' PC is "not sufficiently monstrous", *).
even GCC has much faster iteration times (at least in the sense one can
"actually get something done", rather than just spend the whole day just
waiting for LLVM to recompile).
*: process may basically grind to a halt with HDD thrashing or result in
the PC hard-freezing, "4GB of RAM and a 2GHz Celeron ain't enough for
this". even a higher-end "rig" with 16GB and a Phenom II may still have
a hard time. it is sorta managable on a PC with 32GB of RAM, an AMD-FX,
a huge pagefile (112 GB), and an SSD (mostly for OS and huge pagefile),
and even then it is still pretty slow ("rebuilding LLVM, now time to go
off and watch some anime or something...").
like, not everyone has whatever sort of beast-like PCs the main devs are
using to rebuild this thing...
at least with a small one-off compiler, one can have a reasonably fast
build and iteration times.
while one could argue for using LCC as a front-end, it doesn't take much
to realize LCC is basically a parser + AST walker, and as a result one
either still needs to do most of the "hard part" themselves (or be faced
with some particularly lackluster code generation).
though, if one goes through it a few times "separation of concerns"
becomes relevant, and if the input to the backend is mostly precooked
three-address-code or similar, making a backend isn't quite as hard.
well, apart from ISA issues, like fun with things like getting constants
loaded into variables, dealing with displacements that are small or only
exist for certain types, finding something useful to put into the
"branch delay slot", or checking dependencies between logical
instructions to get them loaded into an "instruction-block"/"packet", ...
so, for example, loading a 64-bit constant requires 4 operations, which
may be done in parallel with 3 or 4 other instructions; and a branch
effectively needs to be placed 8 or so instructions before the point at
which the branch takes place (but, not more than this, as there are two
instruction blocks in the delay-slot; ...).
though, for most other use-cases, there are only really a few targets
which "actually matter" at this point:
* Windows x64
* Linux x86_64
* Linux ARM
** though A64 is making inroads.
and, for others, there is typically a particular target one has in mind.
or, there is some reason in particular one is writing a compiler backend
in the first place.
and, for many HLLs, it is sufficient to basically just write a bytecode
interpreter, and only do JITs for maybe a few select targets (ex: x64
and ARM/Thumb). runs pretty much anywhere, even if the result is slow
apart from the main targets.
or, for other use-cases, one can transpile to C and use an existing
compiler to target the architecture.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-02-14 11:36 +1300 |
| Message-ID | <feh7j8Fhu2iU1@mid.individual.net> |
| In reply to | #126674 |
On 02/14/2018 07:28 AM, BGB wrote: > On 2/13/2018 2:55 AM, David Brown wrote: >> >> If you are making a language that is a reasonable fit for llvm, then why >> not use it? Rather than spending months making a limited little code >> generator for a single processor on a single OS, you can get a big, >> powerful system for free, with vastly more features. Sure, it might >> take you a week to read through the documentation and play around with >> it - but it is a week, not months, and the result is far beyond what you >> would achieve in years. > > however, if in the nature of the project (say, targeting a > custom/experimental CPU arch), and one needs to rebuild LLVM multiple > times, then there is a problem... (or if even trying to build it once, > and ones' PC is "not sufficiently monstrous", *). > > even GCC has much faster iteration times (at least in the sense one can > "actually get something done", rather than just spend the whole day just > waiting for LLVM to recompile). It can be a bit of a beast (it takes about 10 minutes to clean build llvm+clang on what Rolls Royce would have described as an "adequate" machine), how often do you have to rebuild the whole thing? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-14 00:59 +0000 |
| Message-ID | <wRLgC.30074$w26.11712@fx47.am4> |
| In reply to | #126682 |
On 13/02/2018 22:36, Ian Collins wrote: > On 02/14/2018 07:28 AM, BGB wrote: >> On 2/13/2018 2:55 AM, David Brown wrote: >>> >>> If you are making a language that is a reasonable fit for llvm, then why >>> not use it? Rather than spending months making a limited little code >>> generator for a single processor on a single OS, you can get a big, >>> powerful system for free, with vastly more features. Sure, it might >>> take you a week to read through the documentation and play around with >>> it - but it is a week, not months, and the result is far beyond what you >>> would achieve in years. >> >> however, if in the nature of the project (say, targeting a >> custom/experimental CPU arch), and one needs to rebuild LLVM multiple >> times, then there is a problem... (or if even trying to build it once, >> and ones' PC is "not sufficiently monstrous", *). >> >> even GCC has much faster iteration times (at least in the sense one can >> "actually get something done", rather than just spend the whole day just >> waiting for LLVM to recompile). > > It can be a bit of a beast (it takes about 10 minutes to clean build > llvm+clang on what Rolls Royce would have described as an "adequate" > machine), how often do you have to rebuild the whole thing? On the compiler project I'm overhauling at the minute [20-24Kloc], I recompile from scratch every time I run it. Since it takes a few tens of milliseconds, I hadn't noticed; it take me longer to press the Enter key. Yours is a different world I think. (And in the compiled code that does that job, the timer resolution isn't fine enough to measure the difference between compiling it via C with gcc-O3, and my own compiler.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-02-14 15:19 +1300 |
| Message-ID | <fehkmfFhu2iU2@mid.individual.net> |
| In reply to | #126683 |
On 02/14/2018 01:59 PM, bartc wrote: > On 13/02/2018 22:36, Ian Collins wrote: >> On 02/14/2018 07:28 AM, BGB wrote: >>> On 2/13/2018 2:55 AM, David Brown wrote: >>>> >>>> If you are making a language that is a reasonable fit for llvm, then why >>>> not use it? Rather than spending months making a limited little code >>>> generator for a single processor on a single OS, you can get a big, >>>> powerful system for free, with vastly more features. Sure, it might >>>> take you a week to read through the documentation and play around with >>>> it - but it is a week, not months, and the result is far beyond what you >>>> would achieve in years. >>> >>> however, if in the nature of the project (say, targeting a >>> custom/experimental CPU arch), and one needs to rebuild LLVM multiple >>> times, then there is a problem... (or if even trying to build it once, >>> and ones' PC is "not sufficiently monstrous", *). >>> >>> even GCC has much faster iteration times (at least in the sense one can >>> "actually get something done", rather than just spend the whole day just >>> waiting for LLVM to recompile). >> >> It can be a bit of a beast (it takes about 10 minutes to clean build >> llvm+clang on what Rolls Royce would have described as an "adequate" >> machine), how often do you have to rebuild the whole thing? > > On the compiler project I'm overhauling at the minute [20-24Kloc], I > recompile from scratch every time I run it. Since it takes a few tens of > milliseconds, I hadn't noticed; it take me longer to press the Enter key. > > Yours is a different world I think. I only tinker round the edges with llvm, enough to understand how best to use the tools on other projects. I would have thought as a language developer you would welcome tools that do all of the back-end legwork for you. All you would have to do is generate LLVM bitcode and the llvm tools would handle the reset for any supported platform -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-14 14:07 +0000 |
| Message-ID | <moXgC.4620$VP3.3316@fx06.am4> |
| In reply to | #126684 |
On 14/02/2018 02:19, Ian Collins wrote: > On 02/14/2018 01:59 PM, bartc wrote: >> Yours is a different world I think. > > I only tinker round the edges with llvm, enough to understand how best > to use the tools on other projects. > > I would have thought as a language developer you would welcome tools > that do all of the back-end legwork for you. Where's the fun in that? And if you do that, why not let others design the language as well? The you don't have to do ANYTHING! The whole point of this is doing it all yourself, using simple approaches, and ending up with something that is small as well as simple. That approach worked extremely well in the 80s (it had to), and it's fun doing the same now. Anyway, if I wanted a professional back-end, I can just emit C source and run gcc-O3 or MSVC /O2 on it (or someone else can run clang). /I/ don't need to be involved with those products or for them to affect the development, which most of the time will be tested with my own back-end. > All you would have to do > is generate LLVM bitcode and the llvm tools would handle the reset for > any supported platform I haven't looked at it for a while, but I understood then you used a library to do that, and that library has a C++ interface. But I've also seen intermediate code written as source that could conceivably be written by any program. The problem is, it's complicated. And that fact is, the difference in performance between by own crappy code generators, and the best from a professional compiler, is usually not significant when measured across a real application rather than some benchmark which might show a 500% benefit using gcc. Some figures I posted yesterday showed a 20% improvement on one test, using gcc or MSVC, for a computationally intensive app (no outside libraries being called). The advantage is I can use a very simple 0.5M toolchain and not rely on thousands of files and tens or hundreds of MB of programs of some sprawling installation. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-06 15:46 +0000 |
| Message-ID | <GJynC.160633$wa1.19054@fx22.am4> |
| In reply to | #126690 |
On 14/02/2018 14:07, bartc wrote: > On 14/02/2018 02:19, Ian Collins wrote: >> I would have thought as a language developer you would welcome tools >> that do all of the back-end legwork for you. >> All you would have to do is generate LLVM bitcode and the llvm tools >> would handle the reset for any supported platform > The problem is, it's complicated. When I looked at LLVM a decade ago, I counted 44 /sets/ of documentation. Looking today at: http://llvm.org/docs/ there seem to be 89 sets, double the number. There are good reasons for simpler and much smaller alternatives being welcomed. (At least, by people who don't have a business selling 'build farms' or whatever it is you [Ian] do, when the it's the bigger the better.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2018-02-13 20:31 -0600 |
| Message-ID | <p6070i$1qb$1@news.albasani.net> |
| In reply to | #126682 |
On 2/13/2018 4:36 PM, Ian Collins wrote: > On 02/14/2018 07:28 AM, BGB wrote: >> On 2/13/2018 2:55 AM, David Brown wrote: >>> >>> If you are making a language that is a reasonable fit for llvm, then why >>> not use it? Rather than spending months making a limited little code >>> generator for a single processor on a single OS, you can get a big, >>> powerful system for free, with vastly more features. Sure, it might >>> take you a week to read through the documentation and play around with >>> it - but it is a week, not months, and the result is far beyond what you >>> would achieve in years. >> >> however, if in the nature of the project (say, targeting a >> custom/experimental CPU arch), and one needs to rebuild LLVM multiple >> times, then there is a problem... (or if even trying to build it once, >> and ones' PC is "not sufficiently monstrous", *). >> >> even GCC has much faster iteration times (at least in the sense one can >> "actually get something done", rather than just spend the whole day just >> waiting for LLVM to recompile). > > It can be a bit of a beast (it takes about 10 minutes to clean build > llvm+clang on what Rolls Royce would have described as an "adequate" > machine), how often do you have to rebuild the whole thing? > for building LLVM+Clang, I was seeing build times closer to around 40-50 minutes (when I had been messing with it some a few months ago). in contrast, building GCC is about 7-9 minutes (for an incremental rebuild), and around 20 minutes to clean and do a full rebuild. for reference, Doom 3 needs around 15 minutes to rebuild on my PC. in contrast: Quake 1 (built with GCC) is around 35 seconds. Quake 1 is around 8 seconds if built with MSVC, and around 6 seconds with my compiler (... somehow ...). my compiler, similarly, can be itself rebuilt in around 10 seconds or so (with MSVC). special properties: it is plain C and "not huge". all this is on an AMD-FX 8350 (4GHz) with 32GB of DDR3-1600 RAM running Windows 10, a 1TB SSD and with a 112GB pagefile (with both the OS and pagefile on the SSD). in this case, LLVM was being built via WSL. nothing I have a "real" Linux on is seemingly has enough RAM to manage to get LLVM built on; and my previous attempts were unable to get it to build natively on Windows. when I rebuilt LLVM before, generally I was seeing a number of instances of "ld" in task manager, each typically using between around 8 and 12 GB (hence the 112GB pagefile). this property appears to be mostly unique to LLVM. it doesn't take much of this to be discouraging... meanwhile, with my compiler, I can make small tweaks to the compiler, rebuild the compiler, rebuild the program being tested, and then run the program, with a relatively modest cycle time. in a way, this is kind of funny, considering my compiler was originally dismally slow and used excessive amounts of memory, but over time I have rewritten much of it, and more recently partly reworking the AST system led to a fairly significant speedup. ...
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-02-14 15:42 +1300 |
| Message-ID | <fehm0kFhu2iU3@mid.individual.net> |
| In reply to | #126685 |
On 02/14/2018 03:31 PM, BGB wrote: > On 2/13/2018 4:36 PM, Ian Collins wrote: >> On 02/14/2018 07:28 AM, BGB wrote: >>> >>> however, if in the nature of the project (say, targeting a >>> custom/experimental CPU arch), and one needs to rebuild LLVM multiple >>> times, then there is a problem... (or if even trying to build it once, >>> and ones' PC is "not sufficiently monstrous", *). >>> >>> even GCC has much faster iteration times (at least in the sense one can >>> "actually get something done", rather than just spend the whole day just >>> waiting for LLVM to recompile). >> >> It can be a bit of a beast (it takes about 10 minutes to clean build >> llvm+clang on what Rolls Royce would have described as an "adequate" >> machine), how often do you have to rebuild the whole thing? >> > > for building LLVM+Clang, I was seeing build times closer to around 40-50 > minutes (when I had been messing with it some a few months ago). > <snip> > > all this is on an AMD-FX 8350 (4GHz) with 32GB of DDR3-1600 RAM running > Windows 10, a 1TB SSD and with a 112GB pagefile (with both the OS and > pagefile on the SSD). My build nodes are custom, but on my desktop (Ryzen 1800X, 64GB) build times with ninja are 13-14 minutes. > in this case, LLVM was being built via WSL. > > nothing I have a "real" Linux on is seemingly has enough RAM to manage > to get LLVM built on; and my previous attempts were unable to get it to > build natively on Windows. > > when I rebuilt LLVM before, generally I was seeing a number of instances > of "ld" in task manager, each typically using between around 8 and 12 GB > (hence the 112GB pagefile). > > this property appears to be mostly unique to LLVM. Not uncommon with large statically linked C++ application unfortunately. My build node ended up using over 90GB during the link and got a little upset... For our own code we have modified the generated ninja build files to restrict the number of concurrent links. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2018-02-14 01:13 -0600 |
| Message-ID | <p60ni8$6un$1@news.albasani.net> |
| In reply to | #126686 |
On 2/13/2018 8:42 PM, Ian Collins wrote: > On 02/14/2018 03:31 PM, BGB wrote: >> On 2/13/2018 4:36 PM, Ian Collins wrote: >>> On 02/14/2018 07:28 AM, BGB wrote: >>>> >>>> however, if in the nature of the project (say, targeting a >>>> custom/experimental CPU arch), and one needs to rebuild LLVM multiple >>>> times, then there is a problem... (or if even trying to build it once, >>>> and ones' PC is "not sufficiently monstrous", *). >>>> >>>> even GCC has much faster iteration times (at least in the sense one can >>>> "actually get something done", rather than just spend the whole day >>>> just >>>> waiting for LLVM to recompile). >>> >>> It can be a bit of a beast (it takes about 10 minutes to clean build >>> llvm+clang on what Rolls Royce would have described as an "adequate" >>> machine), how often do you have to rebuild the whole thing? >>> >> >> for building LLVM+Clang, I was seeing build times closer to around 40-50 >> minutes (when I had been messing with it some a few months ago). >> > <snip> >> >> all this is on an AMD-FX 8350 (4GHz) with 32GB of DDR3-1600 RAM running >> Windows 10, a 1TB SSD and with a 112GB pagefile (with both the OS and >> pagefile on the SSD). > > My build nodes are custom, but on my desktop (Ryzen 1800X, 64GB) build > times with ninja are 13-14 minutes. > I got an FX because: * my Phenom II / K10 was crapping out; ** had to underclock as it was no longer passing POST reliably at stock. ** also ran a bit more stable with underclock and slight undervolt. * around the time of the Ryzen release the FX was much cheaper. * the FX is at least a little faster vs my K10, but not drastically. ** the performance is a little hit-or-miss in some areas. I might have made more effort to get a Ryzen if I had realized it would be somewhat faster than the FX. in this case, I am not sure if this is more due to the CPU, RAM, or the speed of IO to the pagefile. had noted before that my PC seems to have a memcpy speed of around 3.2GB/s or so; and an SSD IO speed of around 325 MB/s. contrast, my older K10 had a memcpy speed of ~1.8 GB/s; but curiously enough, another box with the same RAM speed (DDR3 1333) got a 2.4 GB/s memcpy... memcpy speed gets funky with multiple threads, seemingly two threads can get ~ 2x the memcpy, but with more threads it quickly drops off. though, I have an old Xeon rack server (which someone was throwing out), which while slower than my main PC with 1 or 2 threads, seems to keep getting faster with more threads, and is actually pretty fast with all cores active (could be pretty scary if this were a PC). also funny is despite it having a pair of quad-core Xeons, memtest86 seems to misidentify it as a "Core 2 Duo"... only 8GB of RAM though, and seemingly surprisingly fast despite being only 2.33 GHz (in many regards nearly the opposite of the 2GHz Celeron). I remembered initially being mildly surprised that somehow code running on a 2.33 GHz Xeon was managing to outperform a Phenom II running at 3.0 GHz (though, both benchmark sites and GHz values implied the Phenom II should have been faster; but even single-threaded the Xeon had a faster memcpy speed and gave better code performance, ...). >> in this case, LLVM was being built via WSL. >> >> nothing I have a "real" Linux on is seemingly has enough RAM to manage >> to get LLVM built on; and my previous attempts were unable to get it to >> build natively on Windows. >> >> when I rebuilt LLVM before, generally I was seeing a number of instances >> of "ld" in task manager, each typically using between around 8 and 12 GB >> (hence the 112GB pagefile). >> >> this property appears to be mostly unique to LLVM. > > Not uncommon with large statically linked C++ application unfortunately. > My build node ended up using over 90GB during the link and got a little > upset... For our own code we have modified the generated ninja build > files to restrict the number of concurrent links. > I didn't mess with settings too much here... most of my own stuff is plain C, so I can mostly sidestep a lot of this... closest I got is with when doing "single translation unit" builds and using a 32-bit compiler, there is a need to not throw "too much" at the compiler all at once (or else it runs out of memory and dies). in my own tests, this seemed to be in the area of ~ 70 .. 100 kLOC (though, compiler performance seemed to drop off some past ~ 30 .. 50). but, this practice is still nifty as it can get most things here down to a matter of a few seconds. my C compiler doesn't seem to benefit as much from single-translation-unit though, but sort of "merges" everything in the program image into a single shared context (only really the preprocessor and parser are fully independent; and the backend operates on a whole program image). otherwise, it seems the IO to fetch headers from the filesystem is a surprising amount of the total compile time. though, I once had it down to around 4 seconds (to rebuild Quake), but lost some time mostly by adding optimizations and some other features in the backend. there is no actual linker stage (nor an assembler stage). note that the use of external serialized stack bytecode IR was actually a workaround for the lack of a linker. otherwise, the compiler would also need to parse and compile all the libraries as well to build a statically-linked program. also used a stack-machine here as one remained as a part of the infrastructure from its early days, and I realized that serializing and reloading from a stack IR was a comparably simpler matter than doing so for the lower level 3AC/SSA IR (doing something similar to LLVM bitcode would have been more effort). but, OTOH, this runs into the issue that there are so many ways such things can be structured. so, for example, my C compiler uses a begin/end block-structured representation with bytecode ops carrying types implicitly via the stack, and variables/functions/... identified symbolically (for example, a operation refers to the name of the variable or function, rather than giving the index of a "constant pool" entry or similar which describes it). in contrast, my BS2 VM uses an program-image-oriented format (with a large central "constant pool", ...), and bytecode ops which carry explicit type information. so, sort of like JVM bytecode if the entire program were a single massive class file (in this sense vaguely like a CLR image, just with a linear constant-pool in place of some bit-twiddled database-like structure, just with the constant pool actually being an indirect offset/index table sort of more like in the RIFF/AVI format and metadata given in a TLV format vaguely akin to ASN.1 BER, ...). or such...
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-02-21 15:13 +0000 |
| Message-ID | <slrnp8r34v.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #126686 |
On Wed, 2018-02-14, Ian Collins wrote: > On 02/14/2018 03:31 PM, BGB wrote: ... >> when I rebuilt LLVM before, generally I was seeing a number of instances >> of "ld" in task manager, each typically using between around 8 and 12 GB >> (hence the 112GB pagefile). >> >> this property appears to be mostly unique to LLVM. > > Not uncommon with large statically linked C++ application unfortunately. > My build node ended up using over 90GB during the link and got a little > upset... For our own code we have modified the generated ninja build > files to restrict the number of concurrent links. Is this with link-time optimization? As far as I can tell, tradi- tional static linking shouldn't have to keep more in memory than the symbols seen so far. (I also believe linking N object files is less efficient than linking against a static library containing N object files, but I don't have any evidence for that.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-02-21 08:43 -0800 |
| Message-ID | <e1c90d39-e858-4536-815c-9165776aa5ca@googlegroups.com> |
| In reply to | #126929 |
On Wednesday, February 21, 2018 at 9:13:55 AM UTC-6, Jorgen Grahn wrote: > Is this with link-time optimization? As far as I can tell, tradi- > tional static linking shouldn't have to keep more in memory than the > symbols seen so far. Even without link-time optimization, it's been common for linking to be the most time consuming part of a build. It's possible to link programs using less memory than would be needed to hold all the symbols, if one makes use of temporary files along with sorting and merge operations. If one has enough memory for all the symbols definitions, however, and object files are formatted suitably, it should be possible to perform a basic link operation in two passes, with pass 1 using one sequential read for each object file's imports and exports list, and with pass 2 skipping that and using one sequential read for everything else.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-02-21 19:21 +0000 |
| Message-ID | <slrnp8rhlp.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #126932 |
On Wed, 2018-02-21, supercat@casperkitty.com wrote: > On Wednesday, February 21, 2018 at 9:13:55 AM UTC-6, Jorgen Grahn wrote: >> Is this with link-time optimization? As far as I can tell, tradi- >> tional static linking shouldn't have to keep more in memory than the >> symbols seen so far. > > Even without link-time optimization, it's been common for linking to be the > most time consuming part of a build. Not in my experience (with the Gnu toolchain) which is part of the reason I'm asking. My link times are roughly what I'd expect if most time spent was disk I/O (lots of mainly debug information to copy from N files to one file). > It's possible to link programs using less memory than would be > needed to hold all the symbols, if one makes use of temporary files > along with sorting and merge operations. I meant, just keeping track of the global /symbols/ isn't likely to take 18 gigabytes of memory, or whatever was reported upthread. > If one has enough memory for all the symbols definitions, however, > and object files are formatted suitably, it should be possible to > perform a basic link operation in two passes, with pass 1 using one > sequential read for each object file's imports and exports list, and > with pass 2 skipping that and using one sequential read for > everything else. I was hoping for one pass, but haven't thought it through. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-02-21 12:25 -0600 |
| Message-ID | <c3er8d1gtuqh379v1e7338d19u85j6ooki@4ax.com> |
| In reply to | #126929 |
On 21 Feb 2018 15:13:35 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: >On Wed, 2018-02-14, Ian Collins wrote: >> On 02/14/2018 03:31 PM, BGB wrote: >... >>> when I rebuilt LLVM before, generally I was seeing a number of instances >>> of "ld" in task manager, each typically using between around 8 and 12 GB >>> (hence the 112GB pagefile). >>> >>> this property appears to be mostly unique to LLVM. >> >> Not uncommon with large statically linked C++ application unfortunately. >> My build node ended up using over 90GB during the link and got a little >> upset... For our own code we have modified the generated ninja build >> files to restrict the number of concurrent links. > >Is this with link-time optimization? As far as I can tell, tradi- >tional static linking shouldn't have to keep more in memory than the >symbols seen so far. > >(I also believe linking N object files is less efficient than linking >against a static library containing N object files, but I don't have >any evidence for that.) Most library formats are just collections of mostly unchanged individual object files packed into a single file. So once the actual object has been read, there really can't be any difference. That being said there are two differences between the two: In the case of individual object files, you do have the additional overhead of opening and closing the individual files. With a single library, you'll have less of that, you only need to open the library file once. You may also have less (effective) file system fragmentation with the library. On the other hand, most object files in libraries are selected after searching them for symbols still unresolved in the build. That search doesn't have to happen with individual object files, since they're explicitly linked.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-02-21 19:28 +0000 |
| Message-ID | <slrnp8ri3l.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #126941 |
On Wed, 2018-02-21, Robert Wessel wrote: > On 21 Feb 2018 15:13:35 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se> > wrote: ... >>(I also believe linking N object files is less efficient than linking >>against a static library containing N object files, but I don't have >>any evidence for that.) > > Most library formats are just collections of mostly unchanged > individual object files packed into a single file. So once the actual > object has been read, there really can't be any difference. Which library formats are those? The GNU ar one (surely the most popular?) also keeps an index. I haven't measured the benefits of that, but I'd expect there to be some. > That being said there are two differences between the two: In the > case of individual object files, you do have the additional overhead > of opening and closing the individual files. With a single library, > you'll have less of that, you only need to open the library file once. > You may also have less (effective) file system fragmentation with the > library. On the other hand, most object files in libraries are > selected after searching them for symbols still unresolved in the > build. That search doesn't have to happen with individual object > files, since they're explicitly linked. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-02-21 18:29 -0600 |
| Message-ID | <tj3s8dpbhcdtm0819n83bqmcn8vkge2hlo@4ax.com> |
| In reply to | #126947 |
On 21 Feb 2018 19:28:53 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: >On Wed, 2018-02-21, Robert Wessel wrote: >> On 21 Feb 2018 15:13:35 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se> >> wrote: >... > >>>(I also believe linking N object files is less efficient than linking >>>against a static library containing N object files, but I don't have >>>any evidence for that.) >> >> Most library formats are just collections of mostly unchanged >> individual object files packed into a single file. So once the actual >> object has been read, there really can't be any difference. > >Which library formats are those? The GNU ar one (surely the most >popular?) also keeps an index. I haven't measured the benefits of >that, but I'd expect there to be some. Sure, some do, but the index doesn't help with anything other than the search for a matching symbol to select an object file from the library to include in the link.
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web