Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #140005 > unrolled thread
| Started by | Bart <bc@freeuk.com> |
|---|---|
| First post | 2019-01-20 00:03 +0000 |
| Last post | 2019-01-21 00:13 -0600 |
| Articles | 20 on this page of 160 — 17 participants |
Back to article view | Back to comp.lang.c
Compiler tests Bart <bc@freeuk.com> - 2019-01-20 00:03 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-20 16:52 +1300
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-20 10:27 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 12:37 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 13:08 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 15:02 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 17:31 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 17:08 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 21:40 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 22:41 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 00:39 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 00:36 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-21 16:33 +1300
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 11:58 +0000
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 04:15 -0800
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-22 07:53 +1300
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 01:15 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 12:00 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-24 08:13 +1300
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 13:30 -0600
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 08:22 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 12:23 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 14:42 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 14:17 +0000
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 12:46 -0800
You guys really, really need to get a room (Was: Compiler tests) gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-24 14:05 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 17:27 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 17:19 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 09:44 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 12:49 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 15:31 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-21 14:38 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-21 15:15 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-21 16:05 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 16:39 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 12:51 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 00:16 +0000
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-22 08:43 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:31 +0000
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-22 17:49 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-23 11:04 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 11:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 15:35 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 15:49 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-21 17:42 +0100
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 03:18 -0600
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 11:11 +0100
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 12:18 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 13:56 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 10:55 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:07 +0000
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 04:29 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:52 +0000
Re: Compiler tests mark.bluemel@gmail.com - 2019-01-22 05:04 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:18 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:45 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:35 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 15:10 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 17:30 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 23:02 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 23:14 +0000
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 15:45 -0800
Re: Compiler tests Robert Wessel <robertwessel2@yahoo.com> - 2019-01-22 17:57 -0600
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 16:36 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 01:37 +0000
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 18:53 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 09:42 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 09:22 +0100
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 08:52 -0500
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 15:13 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 14:33 +0000
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 07:30 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:05 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 17:17 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:29 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 22:04 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 21:50 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 10:45 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 11:55 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 13:58 +0100
Re: Compiler tests mark.bluemel@gmail.com - 2019-01-24 05:07 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 14:10 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 14:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 15:51 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 15:44 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 17:32 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-24 19:07 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 20:14 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 22:24 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 22:46 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-25 12:34 +1300
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 01:01 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-25 14:15 +1300
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 10:05 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:51 +0000
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 09:48 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 10:56 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 12:08 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 13:28 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 13:33 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:38 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 15:08 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 13:53 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 12:25 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 10:03 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 10:08 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 11:14 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 12:02 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 13:37 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 13:58 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:26 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 15:01 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:42 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 10:25 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:37 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 16:33 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:44 -0800
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 17:53 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 10:33 -0800
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 20:43 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 12:17 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 18:31 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 20:41 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 21:19 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-26 10:24 +1300
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 22:27 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 22:39 +0000
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 18:46 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 12:43 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:37 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:19 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:47 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:17 -0800
Re: Compiler tests Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-03 07:28 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-02-03 12:35 +0100
Re: Compiler tests Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-03 21:47 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-02-03 22:57 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-24 06:47 -0800
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-23 20:22 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 22:12 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-23 21:54 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 11:41 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-24 23:17 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 11:11 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 12:04 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:05 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 18:40 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 22:36 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 22:15 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-25 14:48 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-25 14:46 +0000
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 17:48 +0000
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 08:23 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 16:41 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 17:28 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 20:23 +0000
Re: Compiler tests Robert Wessel <robertwessel2@yahoo.com> - 2019-01-22 17:52 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 20:17 +0000
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-21 00:13 -0600
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2019-01-23 11:04 +0100 |
| Message-ID | <q29e6h$8vl$1@dont-email.me> |
| In reply to | #140092 |
Le 22/01/2019 à 17:49, jacobnavia a écrit : > Le 22/01/2019 à 13:31, Bart a écrit : >> It's when generating .exe that my assembler goes wrong shortly after >> exceeding 32K relocation items (which are 'addr64_rel', not even >> absolute). > > All relocation entries are in the .reloc section. They are stored in > blocks, each block starting with the base address (rva) over 4 bytes, > followed by the number of bytes in the using another 4 bytes. > > So, you have up to 2GB of blocks and up to 2GB of block size. > > Within each block you have 16 bit records with the higher 2 bits for the > type of the relocation and the following 12 bits for the address of the > relocation within the block. There is nowhere a 32K limit ... you must > be conbfusing something. In the OBJECT file format there is one, but > absolutely not in the .EXE format, unless you are using the obselete EXE > format of 16 bit windows (Windows 3.1 or so) > As usual, when cofronted with bare facts, Bart is silent: no answer... Much easier to rant endlessly with other people here that like that kind of game
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-23 11:18 +0000 |
| Message-ID | <L3Y1E.131542$ns2.6245@fx26.am4> |
| In reply to | #140111 |
On 23/01/2019 10:04, jacobnavia wrote: > Le 22/01/2019 à 17:49, jacobnavia a écrit : >> Le 22/01/2019 à 13:31, Bart a écrit : >>> It's when generating .exe that my assembler goes wrong shortly after >>> exceeding 32K relocation items (which are 'addr64_rel', not even >>> absolute). >> >> All relocation entries are in the .reloc section. They are stored in >> blocks, each block starting with the base address (rva) over 4 bytes, >> followed by the number of bytes in the using another 4 bytes. >> >> So, you have up to 2GB of blocks and up to 2GB of block size. >> >> Within each block you have 16 bit records with the higher 2 bits for >> the type of the relocation and the following 12 bits for the address >> of the relocation within the block. There is nowhere a 32K limit ... >> you must be conbfusing something. In the OBJECT file format there is >> one, but absolutely not in the .EXE format, unless you are using the >> obselete EXE format of 16 bit windows (Windows 3.1 or so) >> > > As usual, when cofronted with bare facts, Bart is silent: no answer... I made a mistake; there was a 16-bit limit in my program, but to do with the number of symbols (for this test, same as number of relocs). It wasn't an exe format problem. Although the limitation will be there when I generate object files, which is rare (that's needed to generate .dll which needs an external linker). I will leave it as a limitation. In the meantime I've identified some other hard-coded limits which can be breached with extreme programs; I may or not may address those in due course. > Much easier to rant endlessly with other people here that like that kind > of game What's your problem? In parts that you've snipped, I said this: "However it seems PE format (ie. for EXE) doesn't use that relocation info at all. It's used for COFF (ie. object files), which I'm not too concerned about. ... I'll need to look further to see what's happening. ..." I did look further, found the cause, but did not feel the need to announce it here. There were other things to sort out too.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-21 15:35 +0100 |
| Message-ID | <q24lat$hnv$1@dont-email.me> |
| In reply to | #140058 |
On 21/01/2019 14:38, jacobnavia wrote:
> What Mr Brown doesn't take into account is that C is used as a back end
> language for other languages.
I do take that into account. However, I also make the assumption that
the people writing these C generators do so sensibly. That does not
mean the C code should be like manually written code - generated code is
often full of gotos, labels, etc. But your example here shows that the
Eiffel backend could do with a little improvement.
>
> For instance Eiffel.
>
> And some Eiffel compilers generate code for
>
> int table[3]={1,2,3} // Equivalent in Eiffel of course
>
> int main(void)
> {
> table[0]=1; table[1]=2; table[3]=3;
> ...
> }
> What is perfectly legal. Problem is when you have a table with 45000
> entries!
>
> One of my customers was the JPL, that used an Eiffel compiler to
> calculate ephemerides and orbit parameters... My compiler was the only
> one able to compile the "main" function that consisted of thousands and
> thousands of statements like:
> int main()
> {
> // ...
>
> table[34765]=63422; table[34766]=619563; table[34767]=26445;
> // ...
> }
>
> Both gcc and MSVC would fail.
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-21 15:49 +0000 |
| Message-ID | <pSl1E.188124$FF1.29988@fx06.am4> |
| In reply to | #140063 |
On 21/01/2019 14:35, David Brown wrote: > On 21/01/2019 14:38, jacobnavia wrote: >> What Mr Brown doesn't take into account is that C is used as a back end >> language for other languages. > > I do take that into account. However, I also make the assumption that > the people writing these C generators do so sensibly. What's not sensible about just writing one simple assignment followed by another? The scaling limitations of the C compiler that might be used should not be a consideration. Would it be a consideration if you are writing one element of an initialised array after another? If not then why should it be for anything else. This is the complexity of the original source about which little can be done. > That does not > mean the C code should be like manually written code - generated code is > often full of gotos, labels, etc. But your example here shows that the > Eiffel backend could do with a little improvement. Interesting. Something goes wrong with compiling huge numbers of consecutive assignments, but your reaction is that it is the generator program that should be changed** instead of the C compiler. Of course, some C compilers can cope perfectly well, but you would still thing the Eiffel program should be changed rather than C compilers that have trouble? Under what circumstances would you suggest that a program like gcc could do with some work? (** And generate what instead? A sequence of array initialisation elements? Where is your evidence that that is going to help? Without actually testing that repeating lots of identical elements will work better or not, how do you decide? Since any such tests, according to you, are a total waste of time.)
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-21 17:42 +0100 |
| Message-ID | <m2sgxmj723.fsf@despina.home> |
| In reply to | #140066 |
Bart <bc@freeuk.com> writes: > On 21/01/2019 14:35, David Brown wrote: > Interesting. Something goes wrong with compiling huge numbers of > consecutive assignments, but your reaction is that it is the generator > program that should be changed** instead of the C compiler. > > Of course, some C compilers can cope perfectly well, but you would > still thing the Eiffel program should be changed rather than C > compilers that have trouble? Yes, it is expected that compilers, like any other program, may have limitations. Those limitations may be arbitrary and unjustified (then we could complain I guess), or may be due to technical reasons or other. For example, the size of the generated binary code for a single procedure may be limited, so that jumps use short addressing modes or for other constraints. Or the size of the source itself may be limited by the compiler, to avoid the consumption of unbounded resources at compilation time. More specifically: 5.2.4.1 Translation limits The implementation shall be able to translate and execute at least one program that contains at least one instance of every one of the following limits (implementations should avoid imposing fixed translation limits whenever possible): — 127 nesting levels of blocks — 63 nesting levels of conditional inclusion — 12 pointer, array, and function declarators (in any combinations) modifying an arithmetic, structure, union, or void type in a declaration — 63 nesting levels of parenthesized declarators within a full declarator — 63 nesting levels of parenthesized expressions within a full expression — 63 significant initial characters in an internal identifier or a macro name (each universal character name or extended source character is considered a single character) — 31 significant initial characters in an external identifier (each universal character name specifying a short identifier of 0000FFFF or less is considered 6 characters, each universal character name specifying a short identifier of 00010000 or more is considered 10 characters, and each extended source character is considered the same number of characters as the corresponding universal character name, if any) — 4095 external identifiers in one translation unit — 511 identifiers with block scope declared in one block — 4095 macro identifiers simultaneously defined in one preprocessing translation unit — 127 parameters in one function definition — 127 arguments in one function call — 127 parameters in one macro definition — 127 arguments in one macro invocation — 4095 characters in a logical source line — 4095 characters in a string literal (after concatenation) — 65535 bytes in an object (in a hosted environment only) — 15 nesting levels for #included files — 1023 case labels for a switch statement (excluding those for any nested switch statements) — 1023 members in a single structure or union — 1023 enumeration constants in a single enumeration — 63 levels of nested structure or union definitions in a single struct-declaration-list It seems to me that the limit "65535 bytes in an object" would apply to the function body. Or 131071 or anything, but a definite bounded limit. -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2019-01-23 03:18 -0600 |
| Message-ID | <q29bgo$di0$1@news.albasani.net> |
| In reply to | #140067 |
On 1/21/2019 10:42 AM, Pascal J. Bourguignon wrote: > Bart <bc@freeuk.com> writes: > >> On 21/01/2019 14:35, David Brown wrote: >> Interesting. Something goes wrong with compiling huge numbers of >> consecutive assignments, but your reaction is that it is the generator >> program that should be changed** instead of the C compiler. >> >> Of course, some C compilers can cope perfectly well, but you would >> still thing the Eiffel program should be changed rather than C >> compilers that have trouble? > > Yes, it is expected that compilers, like any other program, may have > limitations. > > Those limitations may be arbitrary and unjustified (then we could > complain I guess), or may be due to technical reasons or other. > > For example, the size of the generated binary code for a single > procedure may be limited, so that jumps use short addressing modes or > for other constraints. > Typically also, multiple passes may be used to figure out (among other things), how large of branches are needed. For a strong majority of functions, one may be able to get away with using branches which have an 8 bit displacement. > Or the size of the source itself may be limited by the compiler, to > avoid the consumption of unbounded resources at compilation time. > IIRC, mine currently assumes 16MB both before and after preprocessing. > More specifically: > > 5.2.4.1 Translation limits > > The implementation shall be able to translate and execute at least one > program that contains at least one instance of every one of the > following limits (implementations should avoid imposing fixed > translation limits whenever possible): > > — 127 nesting levels of blocks > > — 63 nesting levels of conditional inclusion > No strict bounds here in my case. > — 12 pointer, array, and function declarators (in any combinations) > modifying an arithmetic, structure, union, or void type in a declaration > Mine uses several representations for a type, with tradeoffs: 1: Up to 7 stars; 1 array level (up to 4095); Base types + 4K complex types. 2: T/T*/T[]/*T[]; 1 array level (up to 1M elems); Primitive types only. 3: as above; 1 array level (up to 63 elems); 1M complex types. 4: overflow case, up to 1M overflowed types. Pretty much anything outside these limits (and pretty much all multidimensional arrays) fall back to the overflow case. The overflow case involves a structure in a table, vs being bit-packed into a 32-bit value for the other cases. The bit twiddling allows the "average case" to remain relatively cheap. > — 63 nesting levels of parenthesized declarators within a full declarator > > — 63 nesting levels of parenthesized expressions within a full expression > No explicit limit. > — 63 significant initial characters in an internal identifier or a macro > name (each universal character name or extended source character is > considered a single character) > > — 31 significant initial characters in an external identifier (each > universal character name specifying a short identifier of 0000FFFF or > less is considered 6 characters, each universal character name > specifying a short identifier of 00010000 or more is considered 10 > characters, and each extended source character is considered the same > number of characters as the corresponding universal character name, if > any) > Both cases are ~ 240 in my case, though limit may be reduced due to name-mangling or similar (with the other languages supported). > — 4095 external identifiers in one translation unit > Current hard-coded limit in my compiler is 256K IIRC, but this is for all symbols in an image (TUs have the same limit). > — 511 identifiers with block scope declared in one block > Hmm, current default limits are 256 for locals, and 32 for static vars. Some logic is in place to allow for these to be expanded dynamically, but nothing currently hits these limits. > — 4095 macro identifiers simultaneously defined in one preprocessing > translation unit > No defined limit. > — 127 parameters in one function definition > > — 127 arguments in one function call > Current limit is 32, could expand dynamically if needed. Currently nothing hits this limit. At least in C, nothing really uses all that many function arguments. Verilog, though, would be another matter, as one may pass like 70 or more arguments to a module, but partly this is because Verilog lacks anything equivalent to a C struct. > — 127 parameters in one macro definition > > — 127 arguments in one macro invocation > Hmm, current default limit is 8. May be, potentially, up to 256, but this case involves a dynamically allocated array. > — 4095 characters in a logical source line > Current limit is 1MB (with macro expansion). Was previously 16kB, but some of my code broke this limit pretty hard. > — 4095 characters in a string literal (after concatenation) > Current "initial limit" is 16kB, but may expand as needed up to several MB. Current limit of 256 chars for a token, which currently applies to normal string literals. The extended triple-quote strings are currently also variable-sized, 16kB up to MB. > — 65535 bytes in an object (in a hosted environment only) > > — 15 nesting levels for #included files > No defined limit. > — 1023 case labels for a switch statement (excluding those for any > nested switch statements) > Current: Initially uses a limit of 512; First overflow goes to 4096; May expand dynamically up to several million cases (1.5^x). Most switches are under 512, but (in some of my code), a few go considerably higher. > — 1023 members in a single structure or union > > — 1023 enumeration constants in a single enumeration > Both are currently 64 (initial), followed by dynamic expansion as needed. > — 63 levels of nested structure or union definitions in a single > struct-declaration-list > No defined limit (in this specific case). > > > > It seems to me that the limit "65535 bytes in an object" would apply to > the function body. > > Or 131071 or anything, but a definite bounded limit. > IME, it is pretty rare to see functions over a few kB, but every so often they can get huge (usually in functions containing a "giant switch of doom"). Once before, one of my "Giant Switch of Doom" functions managed to cause Emscripten to crash, but reported this as a bug and they fixed it. In my ISA design, there is currently an effective size limit on functions of 1MB (for a 32-bit direct branch op). Going beyond this is possible, but the way switch is currently implemented will create problems here.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-23 11:11 +0100 |
| Message-ID | <q29ek9$bom$1@dont-email.me> |
| In reply to | #140110 |
On 23/01/2019 10:18, BGB wrote: > On 1/21/2019 10:42 AM, Pascal J. Bourguignon wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 21/01/2019 14:35, David Brown wrote: >>> Interesting. Something goes wrong with compiling huge numbers of >>> consecutive assignments, but your reaction is that it is the generator >>> program that should be changed** instead of the C compiler. >>> >>> Of course, some C compilers can cope perfectly well, but you would >>> still thing the Eiffel program should be changed rather than C >>> compilers that have trouble? >> >> Yes, it is expected that compilers, like any other program, may have >> limitations. >> >> Those limitations may be arbitrary and unjustified (then we could >> complain I guess), or may be due to technical reasons or other. >> >> For example, the size of the generated binary code for a single >> procedure may be limited, so that jumps use short addressing modes or >> for other constraints. >> > > Typically also, multiple passes may be used to figure out (among other > things), how large of branches are needed. > > For a strong majority of functions, one may be able to get away with > using branches which have an 8 bit displacement. > Often this is done at the assembler level. Compilers can have estimates, which are useful for judging the most efficient code sequences or layouts to improve code localisation, but the final choice of displacement sizes can be done by the assembler. > > IME, it is pretty rare to see functions over a few kB, but every so > often they can get huge (usually in functions containing a "giant switch > of doom"). Inlining can also lead to large functions. Then there is the next step - link-time optimisation. It can also lead to very large functions as it effectively inlines code across compilation units. > > Once before, one of my "Giant Switch of Doom" functions managed to cause > Emscripten to crash, but reported this as a bug and they fixed it. > > > In my ISA design, there is currently an effective size limit on > functions of 1MB (for a 32-bit direct branch op). Going beyond this is > possible, but the way switch is currently implemented will create > problems here.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2019-01-23 12:18 -0600 |
| Message-ID | <q2ab64$ngi$1@news.albasani.net> |
| In reply to | #140112 |
On 1/23/2019 4:11 AM, David Brown wrote:
> On 23/01/2019 10:18, BGB wrote:
>> On 1/21/2019 10:42 AM, Pascal J. Bourguignon wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 21/01/2019 14:35, David Brown wrote:
>>>> Interesting. Something goes wrong with compiling huge numbers of
>>>> consecutive assignments, but your reaction is that it is the generator
>>>> program that should be changed** instead of the C compiler.
>>>>
>>>> Of course, some C compilers can cope perfectly well, but you would
>>>> still thing the Eiffel program should be changed rather than C
>>>> compilers that have trouble?
>>>
>>> Yes, it is expected that compilers, like any other program, may have
>>> limitations.
>>>
>>> Those limitations may be arbitrary and unjustified (then we could
>>> complain I guess), or may be due to technical reasons or other.
>>>
>>> For example, the size of the generated binary code for a single
>>> procedure may be limited, so that jumps use short addressing modes or
>>> for other constraints.
>>>
>>
>> Typically also, multiple passes may be used to figure out (among other
>> things), how large of branches are needed.
>>
>> For a strong majority of functions, one may be able to get away with
>> using branches which have an 8 bit displacement.
>>
>
> Often this is done at the assembler level. Compilers can have
> estimates, which are useful for judging the most efficient code
> sequences or layouts to improve code localisation, but the final choice
> of displacement sizes can be done by the assembler.
>
At present, there is no separate assembler stage in this case, so things
like register allocation, branch length optimization, ..., happen at
roughly the same time.
There is some internal structural separation between the compiler-like
and assembler-like mechanisms. There is also code in place to allow
emitting ASM code, and an ASM parser. Emitting and parsing textual ASM
would add a fair bit to the build time though.
An intermediate option is putting a list of machine instructions into a
queue and then "assembling" this queue, which avoids the serialization
and parsing cost at least.
Though, at least in this sense my current ISA is a bit better behaved
than SuperH or Thumb, where needing to dump blobs of constants at
unpredictable locations creates a mess for reliably estimating branch
distances.
Current ISA expresses constants and displacements inline, so in this
sense is better behaved.
>>
>> IME, it is pretty rare to see functions over a few kB, but every so
>> often they can get huge (usually in functions containing a "giant switch
>> of doom").
>
> Inlining can also lead to large functions.
>
> Then there is the next step - link-time optimisation. It can also lead
> to very large functions as it effectively inlines code across
> compilation units.
>
OK.
As of yet, haven't gotten around yet to the logic needed to support
inlining in my case.
Had figured some inlining would probably probably make sense to be done
at the AST level.
Similarly, I had thus far generally been more focused thus far on size
optimization than performance optimization. Performance optimization
happens indirectly via reducing instruction counts, ...
Current compiler actually goes the other way to some extent, and folds
off some typically repetitive structures into their own functions. This
way they can be called and reused by subsequent functions (and reducing
overall code footprint somewhat). This is generally limited to specific
structures though (ex: prolog and epilog sequences), which follow their
own specific rules.
Though, doing this does involve some internal guesswork and does have a
certain amount of performance impact (branches are not free), so might
later make this an "optimize for size" specific feature.
One other feature my compiler has is the ability to prune away functions
which are never called (and which are not marked as exports), and some
less commonly used features only have their support mechanisms enabled
if they are detected as being used by the program, ...
A lot of my size comparisons across compilers has been against
size-optimized binaries (ex: "-Os" + "strip"). Otherwise, with
performance-oriented settings ("-O2" or "-O3"), GCC and friends produce
rather large binaries in comparison.
Similarly, VS2015 tends to produce large binaries regardless of
settings; though VS2008 does a lot better at being able to produce small
binaries.
Though, size comparisons between compilers and architectures are a
little messy. Particularly if the compilers are not on an even playing
field (say, ability to use potentially egregious/cheating space-saving
tricks; as opposed to doing it purely on the merit of the ISA design and
generating "compact yet efficient" machine code).
So, can't claim any sort of victory, my compiler would need to be able
to win here without "cheating", which at present, it does not...
>>
>> Once before, one of my "Giant Switch of Doom" functions managed to cause
>> Emscripten to crash, but reported this as a bug and they fixed it.
>>
>>
>> In my ISA design, there is currently an effective size limit on
>> functions of 1MB (for a 32-bit direct branch op). Going beyond this is
>> possible, but the way switch is currently implemented will create
>> problems here.
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-23 13:56 +0000 |
| Message-ID | <no_1E.76793$XD2.22791@fx10.am4> |
| In reply to | #140110 |
On 23/01/2019 09:18, BGB wrote: > On 1/21/2019 10:42 AM, Pascal J. Bourguignon wrote: >> Or the size of the source itself may be limited by the compiler, to >> avoid the consumption of unbounded resources at compilation time. >> > > IIRC, mine currently assumes 16MB both before and after preprocessing. >> — 127 nesting levels of blocks >> >> — 63 nesting levels of conditional inclusion >> > > No strict bounds here in my case. > > >> — 12 pointer, array, and function declarators (in any combinations) >> modifying an arithmetic, structure, union, or void type in a >> declaration >> > > Mine uses several representations for a type, with tradeoffs: > 1: Up to 7 stars; 1 array level (up to 4095); Base types + 4K complex > types. > 2: T/T*/T[]/*T[]; 1 array level (up to 1M elems); Primitive types only. > 3: as above; 1 array level (up to 63 elems); 1M complex types. > 4: overflow case, up to 1M overflowed types. >> — 63 nesting levels of parenthesized declarators within a full declarator >> >> — 63 nesting levels of parenthesized expressions within a full expression >> > > No explicit limit. > > >> — 63 significant initial characters in an internal identifier or a macro >> — 31 significant initial characters in an external identifier (each > Both cases are ~ 240 in my case, though limit may be reduced due to > name-mangling or similar (with the other languages supported). > > >> — 4095 external identifiers in one translation unit >> > > Current hard-coded limit in my compiler is 256K IIRC, but this is for > all symbols in an image (TUs have the same limit). > > >> — 511 identifiers with block scope declared in one block >> > > Hmm, current default limits are 256 for locals, and 32 for static vars. > > Some logic is in place to allow for these to be expanded dynamically, > but nothing currently hits these limits. > > >> — 4095 macro identifiers simultaneously defined in one preprocessing >> translation unit > No defined limit. > > >> — 127 parameters in one function definition >> — 127 arguments in one function call >> > > Current limit is 32, could expand dynamically if needed. > Currently nothing hits this limit. >> — 127 parameters in one macro definition >> >> — 127 arguments in one macro invocation >> > > Hmm, current default limit is 8. > > May be, potentially, up to 256, but this case involves a dynamically > allocated array. >> — 4095 characters in a logical source line >> > > Current limit is 1MB (with macro expansion). > > Was previously 16kB, but some of my code broke this limit pretty hard. > > >> — 4095 characters in a string literal (after concatenation) >> > > Current "initial limit" is 16kB, but may expand as needed up to several MB. > > Current limit of 256 chars for a token, which currently applies to > normal string literals. > > The extended triple-quote strings are currently also variable-sized, > 16kB up to MB. > > >> — 65535 bytes in an object (in a hosted environment only) >> >> — 15 nesting levels for #included files >> > > No defined limit. > > >> — 1023 case labels for a switch statement (excluding those for any >> nested switch statements) >> > > Current: > Initially uses a limit of 512; > First overflow goes to 4096; > May expand dynamically up to several million cases (1.5^x). > > Most switches are under 512, but (in some of my code), a few go > considerably higher. > > >> — 1023 members in a single structure or union >> >> — 1023 enumeration constants in a single enumeration >> > > Both are currently 64 (initial), followed by dynamic expansion as needed. > > >> — 63 levels of nested structure or union definitions in a single >> struct-declaration-list >> > > No defined limit (in this specific case). > >> >> >> >> It seems to me that the limit "65535 bytes in an object" would apply to >> the function body. >> >> Or 131071 or anything, but a definite bounded limit. I've had a look at the current hard-coded limits in my C compiler (some of these look a bit low so I've since added an extra zero): max macro arguments 20 max include nesting 20 (I'm not sure what limits on macro nesting are; maybe that is handling by normal recursion. Perhaps someone should post a test.) max #if/#ifdef nesting no limit I think max ## pastes in one macro 100 max pasted tokens per file 7000 type modifiers in one type 20 function params/args 200 switch case range 500 (Number of case values per switch statement. Beyond that it will change to sequential testing.) nested switch stmts 20 max modules 200 params submitted to compiler max dll libs 200 ... max source files 600 submitted .c files plus includes max search dirs 20 max include paths 20 max blocks per function 2100 (This is an artificial limit; blocks are numbered and it was easier to use an array indexed by block no. for info. I'll to try and eliminate it.) max nested blocks 100 max nested loops 100 max types 20000 max source file size no limit (bounded by memory but also max length of one line no limit by 32-bit lengths throughout) max string const length no limit max identifier length 255 (I can extend this by changing a field, but it means a 64-byte struct might as well then become 128 bytes - double the memory usage for little gain. FWIW, the longest identifier I've encountered was 80 characters in an MS header.) max number identifiers no limit max identifiers in block 64K (due to a 16-bit block number field) (Since output is to ASM, there are additional limits in my assembler/linker. That uses a fixed hashtable size, which can be set at anything, but currently 256K symbols.) max size of object not meaningful max functions in file no limit max expr nesting no limit max recursion limit limited by stack size This affects also things like max number of consecutive labels, because something like 'L1: L2: L3: stmt' is actually three nested statements. I would class 'extreme' types of of source into two kinds: those highly unlikely such as expressions nested a million levels deep, and those that you get by by having a million instances of the same thing, which are much more plausible. The latter I'd take more seriously. Somebody may choose to amalgamate code, or uses a naive code generator, and easily end up with large source files.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-22 10:55 +0100 |
| Message-ID | <q26paq$plc$1@dont-email.me> |
| In reply to | #140066 |
On 21/01/2019 16:49, Bart wrote:
> On 21/01/2019 14:35, David Brown wrote:
>> On 21/01/2019 14:38, jacobnavia wrote:
>>> What Mr Brown doesn't take into account is that C is used as a back end
>>> language for other languages.
>>
>> I do take that into account. However, I also make the assumption that
>> the people writing these C generators do so sensibly.
>
> What's not sensible about just writing one simple assignment followed by
> another?
>
> The scaling limitations of the C compiler that might be used should not
> be a consideration.
>
Reality can be a pain sometimes. It turns out that not all C compilers
are equal, and have different strengths and weaknesses.
> Would it be a consideration if you are writing one element of an
> initialised array after another? If not then why should it be for
> anything else. This is the complexity of the original source about which
> little can be done.
>
>> That does not
>> mean the C code should be like manually written code - generated code is
>> often full of gotos, labels, etc. But your example here shows that the
>> Eiffel backend could do with a little improvement.
>
> Interesting. Something goes wrong with compiling huge numbers of
> consecutive assignments, but your reaction is that it is the generator
> program that should be changed** instead of the C compiler.
>
Yes.
Initialising an array by a huge list of assignments is going to be
extremely inefficient at run-time if you have a simple compiler that
does direct translation of the statements. And if you have a more
advanced compiler that will re-organise and optimise these assignments
to improve the run-time efficiency, you have a significant (maybe, as
seen in these tests, insurmountable) load on the compilation stage. And
even if you have an optimising compiler that handles it, the result will
probably still be inefficient - the C code (judging from the partial
snippets) would probably require many individual writes.
It makes a lot more sense to generate better C code from the Eiffel
tool. There's a good chance that the array would be const (Eiffel is a
language aimed at safe coding), so that the array would end up as a
block of data in the executable image with no copying or initialisation
needed.
> Of course, some C compilers can cope perfectly well, but you would still
> thing the Eiffel program should be changed rather than C compilers that
> have trouble?
Yes.
Sure, some C compilers can handle that - but they have their own
disadvantages (as do all compilers). It makes more sense to generate C
code that can work well with a range of compilers, rather than limited
to a few obscure ones.
(I have nothing against lcc-win, and I think it is marvellous that Jacob
has success with it, and it has some interesting and unique features.
But it /is/ obscure, with a tiny market share compared to the "big"
compilers, and it doesn't have the features and support that the big
ones do.)
>
> Under what circumstances would you suggest that a program like gcc could
> do with some work?
I'd be happier to see gcc being able to compile this code successfully.
But I would /still/ recommend generating better C code in the first
place. The priority should be to fix the /real/ problem here -
generating better C array initialisation code would mean that it could
be compiled efficiently (both compile-time and run-time efficiency) on
any C compiler. Improving one C compiler's handling of the poor C code
only helps for that one C compiler.
gcc has a large database of things to fix - bugs (which get higher
priority, of course), and desired features. There are lots of things
that I would like it to do, and I have made a couple of bugzilla reports
myself. But as you are probably aware, compiler developers are humans,
with limited development resources - they can't do everything. They
have to consider something like this and wonder if the benefits are
worth the cost. If not, then support for fast compilation of very large
but fairly simple functions is something that goes on the list of things
to be done when someone has time, or when someone has particular interest.
(And don't forget that gcc /does/ improve all the time. As I have noted
before, there have been bug reports about its handling of large
functions, and it's possible that improvements have been made. I have
not checked this at all.)
>
> (** And generate what instead? A sequence of array initialisation
> elements? Where is your evidence that that is going to help? Without
> actually testing that repeating lots of identical elements will work
> better or not, how do you decide?
>
> Since any such tests, according to you, are a total waste of time.)
>
Yes, generate code like :
int table[3] = { 1, 2, 3 }
If you prefer, you can use C99 designated initialisers - then you can
re-arrange the order as you like:
int table[3] = { [2] = 3, [0] = 1, [1] = 2 };
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-22 12:07 +0000 |
| Message-ID | <QHD1E.216796$1D1.179078@fx29.am4> |
| In reply to | #140076 |
On 22/01/2019 09:55, David Brown wrote:
> On 21/01/2019 16:49, Bart wrote:
>> Interesting. Something goes wrong with compiling huge numbers of
>> consecutive assignments, but your reaction is that it is the generator
>> program that should be changed** instead of the C compiler.
> Initialising an array by a huge list of assignments is going to be
> extremely inefficient at run-time if you have a simple compiler that
> does direct translation of the statements.
How inefficient; have you measured it?
If I do this in my interpreted language:
var words=("aardvark",...,"zygote") # 110,000 elements
this is implemented by 110,000 push instructions at runtime. It adds 0.1
seconds to start up - for interpreted byte-code.
That has to be balanced against other approaches such as reading 110,000
lines from a text file.
> It makes a lot more sense to generate better C code from the Eiffel
> tool.
The C code is fine. The Eiffel to C translator is fine. The Eiffel code
is fine (the programmer has merely created a large table, presumably
required for their application).
But it goes wrong for some largish values on N on certain C compilers.
So of course you choose to fix one of the things that isn't wrong!
Another choice is to switch C compilers (eg. to lccwin). But what really
needs to be fixed are those poor compilers.
(I found a problem with large string tables in mine which I wasn't aware
of - maybe /I/ should have done such tests sooner - and I will now
proceed to fix it.)
> Sure, some C compilers can handle that - but they have their own
> disadvantages (as do all compilers). It makes more sense to generate C
> code that can work well with a range of compilers, rather than limited
> to a few obscure ones.
And how do you find out the capabilities of different compilers when
given somewhat extreme input?
>> Under what circumstances would you suggest that a program like gcc could
>> do with some work?
>
> I'd be happier to see gcc being able to compile this code successfully.
How do you know whether it can or can't?
How do you know how big a table or big a block of assignments gcc can
cope with?
> The priority should be to fix the /real/ problem here -
> generating better C array initialisation code would mean that it could
> be compiled efficiently (both compile-time and run-time efficiency) on
> any C compiler.
I think that's the first time you've expressed such an opinion - writing
code that compiles well with any compiler. Normally you're happy with
using inefficient-looking constructs but that you know your gcc will
collapse down to the essentials.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-01-22 04:29 -0800 |
| Message-ID | <4a55ba02-792a-4490-ab89-c37ad258b652@googlegroups.com> |
| In reply to | #140078 |
W dniu wtorek, 22 stycznia 2019 13:07:21 UTC+1 użytkownik Bart napisał:
> On 22/01/2019 09:55, David Brown wrote:
> > On 21/01/2019 16:49, Bart wrote:
>
> >> Interesting. Something goes wrong with compiling huge numbers of
> >> consecutive assignments, but your reaction is that it is the generator
> >> program that should be changed** instead of the C compiler.
>
> > Initialising an array by a huge list of assignments is going to be
> > extremely inefficient at run-time if you have a simple compiler that
> > does direct translation of the statements.
>
> How inefficient; have you measured it?
>
> If I do this in my interpreted language:
>
> var words=("aardvark",...,"zygote") # 110,000 elements
>
> this is implemented by 110,000 push instructions at runtime. It adds 0.1
> seconds to start up - for interpreted byte-code.
>
> That has to be balanced against other approaches such as reading 110,000
> lines from a text file.
>
> > It makes a lot more sense to generate better C code from the Eiffel
> > tool.
>
> The C code is fine. The Eiffel to C translator is fine. The Eiffel code
> is fine (the programmer has merely created a large table, presumably
> required for their application).
>
> But it goes wrong for some largish values on N on certain C compilers.
>
> So of course you choose to fix one of the things that isn't wrong!
> Another choice is to switch C compilers (eg. to lccwin). But what really
> needs to be fixed are those poor compilers.
>
> (I found a problem with large string tables in mine which I wasn't aware
> of - maybe /I/ should have done such tests sooner - and I will now
> proceed to fix it.)
>
> > Sure, some C compilers can handle that - but they have their own
> > disadvantages (as do all compilers). It makes more sense to generate C
> > code that can work well with a range of compilers, rather than limited
> > to a few obscure ones.
>
> And how do you find out the capabilities of different compilers when
> given somewhat extreme input?
>
> >> Under what circumstances would you suggest that a program like gcc could
> >> do with some work?
> >
> > I'd be happier to see gcc being able to compile this code successfully.
>
> How do you know whether it can or can't?
>
> How do you know how big a table or big a block of assignments gcc can
> cope with?
>
> > The priority should be to fix the /real/ problem here -
> > generating better C array initialisation code would mean that it could
> > be compiled efficiently (both compile-time and run-time efficiency) on
> > any C compiler.
>
> I think that's the first time you've expressed such an opinion - writing
> code that compiles well with any compiler. Normally you're happy with
> using inefficient-looking constructs but that you know your gcc will
> collapse down to the essentials.
i think you again dropped in your loop bartc... of loop of maniacaly repaating
how you see things, and what is interesting to you.. where you are not a center of the world, and rest of the world could sleep better dont even knowing that
besides writing a code to be compiled with every compiler is sorta idiotical
and if you sepnd that much time by sdvertisizing your interpreters and compilers, could you post some for some people to test how bad it realy is?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-22 12:52 +0000 |
| Message-ID | <vmE1E.85801$AD1.76522@fx05.am4> |
| In reply to | #140081 |
On 22/01/2019 12:29, fir wrote: > i think you again dropped in your loop bartc... of loop of maniacaly repaating > how you see things, and what is interesting to you.. where you are not a center of the world, and rest of the world could sleep better dont even knowing that This is to counterbalance David Brown's assertion that the centre of world is gcc. A product that is totally beyond criticism, even when it doesn't work. > besides writing a code to be compiled with every compiler is sorta idiotical Yeah... > > and if you sepnd that much time by sdvertisizing your interpreters and compilers, could you post some for some people to test how bad it realy is? I've done this plenty of times, but it is a huge effort to do especially having to generate the C source versions (and some programs no longer work in C). But if you're happy with Win64 binaries and can deal with AV issues, then try these versions: www.bcas.freeuk.com/mm.exe 'M' compiler www.bcas.freeuk.com/qc.exe 'Q' byte-code compiler www.bcas.freeuk.com/pc.exe 'Q' byte-code interpreter www.bcas.freeuk.com/bcc.exe 'C' subset compiler These are not installers, but the actual programs. Too much trouble to zip them.
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2019-01-22 05:04 -0800 |
| Message-ID | <b1ebaf37-3cef-4c1a-bfd0-c1126fa4af05@googlegroups.com> |
| In reply to | #140083 |
On Tuesday, 22 January 2019 12:52:52 UTC, Bart wrote: > This is to counterbalance David Brown's assertion that the centre of > world is gcc. [citation required] > A product that is totally beyond criticism, even when it > doesn't work. [citation required] >
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-01-22 05:18 -0800 |
| Message-ID | <3c2473bb-f672-490c-9399-6935e751e10c@googlegroups.com> |
| In reply to | #140083 |
W dniu wtorek, 22 stycznia 2019 13:52:52 UTC+1 użytkownik Bart napisał: > On 22/01/2019 12:29, fir wrote: > > > i think you again dropped in your loop bartc... of loop of maniacaly repaating > > how you see things, and what is interesting to you.. where you are not a center of the world, and rest of the world could sleep better dont even knowing that > > This is to counterbalance David Brown's assertion that the centre of > world is gcc. A product that is totally beyond criticism, even when it > doesn't work. > > > besides writing a code to be compiled with every compiler is sorta idiotical > > Yeah... > > > > > and if you sepnd that much time by sdvertisizing your interpreters and compilers, could you post some for some people to test how bad it realy is? > > I've done this plenty of times, but it is a huge effort to do especially > having to generate the C source versions (and some programs no longer > work in C). > > But if you're happy with Win64 binaries and can deal with AV issues, > then try these versions: > > www.bcas.freeuk.com/mm.exe 'M' compiler > www.bcas.freeuk.com/qc.exe 'Q' byte-code compiler > www.bcas.freeuk.com/pc.exe 'Q' byte-code interpreter > www.bcas.freeuk.com/bcc.exe 'C' subset compiler > > These are not installers, but the actual programs. Too much trouble to > zip them. you really should zip them... you also really should give link to it when you talk on those compilers as this changes situation (from talking on something that 90% of discutants have not acces to, to when it can be tested..it realy changes situation) besides exes, ok, im not paranoid to take binaries from people that seems enough sane to not host malware as those discusions you got some problem of 1) saing arguments that are some conclusions of your private liknes which can be contradicted by some other taste of doing things 2) you make loop on this.. this generates sometimes threads which look a bit like discusions from hodgin..this is not much sane content here then...sane content here is something that increases knowledge and understanding not something that just 'eats time' as to those compilers/interpreters i may test them but in due time..downloaded em though
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-01-22 05:45 -0800 |
| Message-ID | <89f9aba2-c9e8-4e98-b8fe-c84acf885992@googlegroups.com> |
| In reply to | #140085 |
W dniu wtorek, 22 stycznia 2019 14:18:50 UTC+1 użytkownik fir napisał: > W dniu wtorek, 22 stycznia 2019 13:52:52 UTC+1 użytkownik Bart napisał: > > > > These are not installers, but the actual programs. Too much trouble to > > zip them. > > you really should zip them... eventualy you may not, fiorst time i seen somebody post stright exes in direct link, but if that work... so be it it resembles me old times when i was newb and i wondered if the folder with executable files 'posted' (in that one case by local network, but in fact it may be via internet like here) when 'run' wil exacute in context of its own local machine, or in context of mine, or somewhat mixxed in both those old ideas are like forgotten (at least for general use) and they are cool imo... its like having milions of computer disc at hand and plaing games from them at home without copying or alternatively like legally runing programs on thousands of other user machines (in their own contextes) those ideas are cool as they are fundamental, orthiogonal (or what to call it) and this grant big tehnical fun imo (not like today when disabilities and policies blocks that many things)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-01-22 05:35 -0800 |
| Message-ID | <6b66143f-0a3f-4d8c-8229-f4955d769586@googlegroups.com> |
| In reply to | #140083 |
W dniu wtorek, 22 stycznia 2019 13:52:52 UTC+1 użytkownik Bart napisał: > On 22/01/2019 12:29, fir wrote: > > > i think you again dropped in your loop bartc... of loop of maniacaly repaating > > how you see things, and what is interesting to you.. where you are not a center of the world, and rest of the world could sleep better dont even knowing that > > This is to counterbalance David Brown's assertion that the centre of > world is gcc. A product that is totally beyond criticism, even when it > doesn't work. > if even so (didnt readed that), so what? isnt saying that you has other opinion once (or 'once a month') didnt suffice? people have variety of opinions and if i would like to fight war on everybody to have some like me i would drown in infinite war (which would kill my life-time i guess) if you got better one you should be happy ypu got better one, isnt it enough ? (rethoric question as i dont go in a loop of discussing hat silly questions) (well maybe questions are not much silly per se, but i dont belive if someone here would be able tos ay something noticable here ;c )
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-22 15:10 +0100 |
| Message-ID | <q27894$a00$1@dont-email.me> |
| In reply to | #140078 |
On 22/01/2019 13:07, Bart wrote:
> On 22/01/2019 09:55, David Brown wrote:
>> On 21/01/2019 16:49, Bart wrote:
>
>>> Interesting. Something goes wrong with compiling huge numbers of
>>> consecutive assignments, but your reaction is that it is the generator
>>> program that should be changed** instead of the C compiler.
>
>> Initialising an array by a huge list of assignments is going to be
>> extremely inefficient at run-time if you have a simple compiler that
>> does direct translation of the statements.
>
> How inefficient; have you measured it?
>
> If I do this in my interpreted language:
>
> var words=("aardvark",...,"zygote") # 110,000 elements
>
> this is implemented by 110,000 push instructions at runtime. It adds 0.1
> seconds to start up - for interpreted byte-code.
Fair enough - it is not a long time on modern cpus.
>
> That has to be balanced against other approaches such as reading 110,000
> lines from a text file.
That is going to be a great deal less than 0.1 seconds, at least with an
SSD or an OS that can cache files properly.
And it has to be balanced against doing it properly in C with an
initialised table.
Just to please you, I made a file with a 1,000,000 entry array of ints,
arranged randomly but initialised properly rather than with a series of
assignments.
int table[1000000] = {
128689,
586686,
436487,
...
Compilation (optimised) is 2 seconds with gcc, or 5 if I used designated
initialisers in a random order:
int table[1000000] = {
[323574] = 128689,
[463931] = 586686,
[114617] = 436487,
...
You'll be pleased to know I gave up waiting for gcc to attempt assignment:
int table[1000000];
int main(void) {
table[323574] = 128689;
table[463931] = 586686;
table[114617] = 436487;
...
Assuming your "push" method is linear (which is unreasonable, as cache
effects would come into play), a million entry table will take about 1
second of startup time. How much startup time does my array
initialisation take? Less than a millisecond - too short to be
measurable by a simple "time" command.
Oh, and just for fun I timed python reading these C files (with their
million lines) - 20 milliseconds. Reading the file and separating them
into lines is 70 milliseconds. On the assumption that reasonable C code
is not going to be much slower than Python, and that my PC is not /that/
much faster than yours, it looks like reading the dictionary from a file
will be a few times faster than your "push" initialisation.
All in all, I think the evidence here is rather clear - initialising
your tables is /massively/ more efficient than assigning to them.
>
>> It makes a lot more sense to generate better C code from the Eiffel
>> tool.
>
> The C code is fine. The Eiffel to C translator is fine. The Eiffel code
> is fine (the programmer has merely created a large table, presumably
> required for their application).
I have no possible way to judge the Eiffel code itself - I don't know
Eiffel, and I haven't seen the code. But the generated C (as shown here
- remember, we know nothing about the tools used, versions, etc.) is
done in a very poor way. It is, of course, entirely possible that this
is due to a direct translation of poor quality Eiffel code.
There is a difference between "technically legal and correct code" and
"good, sensible code".
>
> But it goes wrong for some largish values on N on certain C compilers.
>
> So of course you choose to fix one of the things that isn't wrong!
My choice is to fix the thing that is making awful code.
(As I said before, I would be quite happy to see gcc improved here too.
But it is not the real problem.)
> Another choice is to switch C compilers (eg. to lccwin). But what really
> needs to be fixed are those poor compilers.
>
> (I found a problem with large string tables in mine which I wasn't aware
> of - maybe /I/ should have done such tests sooner - and I will now
> proceed to fix it.)
>
>> Sure, some C compilers can handle that - but they have their own
>> disadvantages (as do all compilers). It makes more sense to generate C
>> code that can work well with a range of compilers, rather than limited
>> to a few obscure ones.
>
> And how do you find out the capabilities of different compilers when
> given somewhat extreme input?
>
At the risk of stating the blindingly obvious, don't give them extreme
input.
Of course the developers of compilers should test with a wide variety of
inputs, and use the results to learn about possible problems or
limitations, and to consider whether they should be doing something
about them.
>>> Under what circumstances would you suggest that a program like gcc could
>>> do with some work?
>>
>> I'd be happier to see gcc being able to compile this code successfully.
>
> How do you know whether it can or can't?
>
You have said it can't. Should I not believe you?
> How do you know how big a table or big a block of assignments gcc can
> cope with?
gcc can cope fine with huge tables. I tested with a million entry
table. It can't cope well with a function with a huge block of
assignments - 10,000 lines took 7 seconds to compile with my test (with
-O2). 100,000 lines took 78 seconds. 1,000,000 lines took 16 minutes.
(This is all with gcc 7, on 64-bit Linux.) Running it took 15 ms,
compared to about 1 ms with table initialisation.
So yes, gcc /can/ compile a function consisting of a million assignment
statements. But by taking 15 minutes, it cannot be said to cope well
with it.
>
>> The priority should be to fix the /real/ problem here -
>> generating better C array initialisation code would mean that it could
>> be compiled efficiently (both compile-time and run-time efficiency) on
>> any C compiler.
>
> I think that's the first time you've expressed such an opinion - writing
> code that compiles well with any compiler. Normally you're happy with
> using inefficient-looking constructs but that you know your gcc will
> collapse down to the essentials.
>
I have always said I have been happy with gcc's speed on /my/ code. I
don't write code with million line functions. I have also always said
that I understand other people wanting faster compilation - primarily
with big C++ projects where header libraries mean massive files (after
#include file handling) - though not massive functions.
And I am happy to write inefficient-looking constructs that I know gcc
will turn into efficient object code - /if/ that is a better way to
write the code.
A large clump of assignments, instead of an array initialisation, is a
/worse/ way to write the code in all reasonable interpretations of
"worse". It is bigger and slower to write, harder to maintain or
change, less clear in the code, ugly and repetitive, stops you from
using "const" - as well as being slower to compile (significantly so,
for big arrays), slower to run, and generating bigger object code.
There simply is no good reason to use it.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-22 17:30 +0000 |
| Message-ID | <2rI1E.118890$dp2.55232@fx18.am4> |
| In reply to | #140089 |
On 22/01/2019 14:10, David Brown wrote:
> On 22/01/2019 13:07, Bart wrote:
>> On 22/01/2019 09:55, David Brown wrote:
>> That has to be balanced against other approaches such as reading 110,000
>> lines from a text file.
>
> That is going to be a great deal less than 0.1 seconds, at least with an
> SSD or an OS that can cache files properly.
> And it has to be balanced against doing it properly in C with an
> initialised table.
Sometimes the data needs to be embedded in the source code. And
sometimes the linear block data from a file needs to be arranged into
the data structures needed.
> Just to please you, I made a file with a 1,000,000 entry array of ints,
> arranged randomly but initialised properly rather than with a series of
> assignments.
>
> int table[1000000] = {
> 128689,
> 586686,
> 436487,
> ...
>
> Compilation (optimised) is 2 seconds with gcc, or 5 if I used designated
> initialisers in a random order:
>
> int table[1000000] = {
> [323574] = 128689,
> [463931] = 586686,
> [114617] = 436487,
> ...
>
> You'll be pleased to know I gave up waiting for gcc to attempt assignment:
>
>
> int table[1000000];
>
> int main(void) {
> table[323574] = 128689;
> table[463931] = 586686;
> table[114617] = 436487;
> ...
>
>
> Assuming your "push" method is linear (which is unreasonable, as cache
> effects would come into play), a million entry table will take about 1
> second of startup time. How much startup time does my array
> initialisation take? Less than a millisecond - too short to be
> measurable by a simple "time" command.
Further tests with that interpreted code show that running "hello" takes
40ms (including process overheads); a program initialising a table of
109K strings takes 70ms; and one for 500K strings takes 180ms. So about
140ms to initialise.
String tables are a little bit harder because it's not just a linear
block of data.
If I do the equivalent test with C, then a program like this:
#include <stdio.h>
char *table[524288];
int main(void) {
int t;
puts("Building table...");
t=clock();
table[0]="ångström";
table[1]="ångströms";
table[2]="übermensch";
....
table[501207]="zyzzyvas";
table[501208]="zz";
table[501209]="zzt";
table[501210]="zzz";
t=clock()-t;
printf("Done; time:%d %s\n",t,table[123456]);
}
took 1.6 seconds to build with Tiny C. Running it took about 100ms
overall. Output is:
Building table...
Done; time:6 dornocks
which suggests the actual initialisation only took 6ms. This is after
all the ultimate unrolled loop. (It's possible that large data incurs
additional overheads when loading the executable to start the process.)
(Don't ask me what 'dornocks' means; this list of words includes
everything.)
However, If I try it with gcc, it runs out of memory.
(My bcc will compile it to .asm in 2.2 seconds, but I need to fix the
problem with its assembler to complete it.
Testing for extreme programs and sorting out the problems that come up
is kinda fun. Just keep me away from PE file formats.)
> Oh, and just for fun I timed python reading these C files (with their
> million lines) - 20 milliseconds. Reading the file and separating them
> into lines is 70 milliseconds.
Doesn't that make you wonder what the hell gcc is doing for 15 minutes,
for processing the same input?
> A large clump of assignments, instead of an array initialisation, is a
> /worse/ way to write the code in all reasonable interpretations of
> "worse".
If there was a better alternative then I would agree. But if using C as
a backend target, then it may simply be more convenient to do it that
way. Maybe the data tables aren't static. Maybe some elements could be
runtime expressions.
So long as its valid C (and there is a LOT worse C written using
macros), then that should be it.
Some people /want/ to use C as a kind of portable assembler where you
throw anything at it, including large blocks of the same thing, and
expect it to just work.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-22 23:02 +0100 |
| Message-ID | <q283te$1fj$1@dont-email.me> |
| In reply to | #140093 |
On 22/01/2019 18:30, Bart wrote:
> On 22/01/2019 14:10, David Brown wrote:
>> On 22/01/2019 13:07, Bart wrote:
>>> On 22/01/2019 09:55, David Brown wrote:
>
>>> That has to be balanced against other approaches such as reading 110,000
>>> lines from a text file.
>>
>> That is going to be a great deal less than 0.1 seconds, at least with an
>> SSD or an OS that can cache files properly.
>
>> And it has to be balanced against doing it properly in C with an
>> initialised table.
>
> Sometimes the data needs to be embedded in the source code. And
> sometimes the linear block data from a file needs to be arranged into
> the data structures needed.
I regularly embed files as data in C code. Given your aversion to build
systems, you'll be horrified to know that for a number of my projects,
"make" uses Python scripts to turn things like images or html files into
C files with const arrays of data. These are defined and initialised as
arrays like
const uint8_t index_html = {
"\x48\x54\x54\x50\x2f\x31 ...
It is written as an initialised array, declared const. Anything else -
such as using assignments in a function - would be insane in a small
embedded system.
>
>> Just to please you, I made a file with a 1,000,000 entry array of ints,
>> arranged randomly but initialised properly rather than with a series of
>> assignments.
>>
>> int table[1000000] = {
>> 128689,
>> 586686,
>> 436487,
>> ...
>>
>> Compilation (optimised) is 2 seconds with gcc, or 5 if I used designated
>> initialisers in a random order:
>>
>> int table[1000000] = {
>> [323574] = 128689,
>> [463931] = 586686,
>> [114617] = 436487,
>> ...
>>
>> You'll be pleased to know I gave up waiting for gcc to attempt
>> assignment:
>>
>>
>> int table[1000000];
>>
>> int main(void) {
>> table[323574] = 128689;
>> table[463931] = 586686;
>> table[114617] = 436487;
>> ...
>>
>>
>> Assuming your "push" method is linear (which is unreasonable, as cache
>> effects would come into play), a million entry table will take about 1
>> second of startup time. How much startup time does my array
>> initialisation take? Less than a millisecond - too short to be
>> measurable by a simple "time" command.
>
> Further tests with that interpreted code show that running "hello" takes
> 40ms (including process overheads); a program initialising a table of
> 109K strings takes 70ms; and one for 500K strings takes 180ms. So about
> 140ms to initialise.
>
> String tables are a little bit harder because it's not just a linear
> block of data.
>
> If I do the equivalent test with C, then a program like this:
>
> #include <stdio.h>
>
> char *table[524288];
>
> int main(void) {
> int t;
>
> puts("Building table...");
> t=clock();
>
> table[0]="ångström";
> table[1]="ångströms";
> table[2]="übermensch";
> ....
> table[501207]="zyzzyvas";
> table[501208]="zz";
> table[501209]="zzt";
> table[501210]="zzz";
>
> t=clock()-t;
> printf("Done; time:%d %s\n",t,table[123456]);
> }
>
> took 1.6 seconds to build with Tiny C. Running it took about 100ms
> overall. Output is:
>
> Building table...
> Done; time:6 dornocks
>
> which suggests the actual initialisation only took 6ms. This is after
> all the ultimate unrolled loop. (It's possible that large data incurs
> additional overheads when loading the executable to start the process.)
>
> (Don't ask me what 'dornocks' means; this list of words includes
> everything.)
>
> However, If I try it with gcc, it runs out of memory.
What gcc version? I had no hints of memory issues with my testing with
gcc 7 and gcc 8. It just took time.
>
> (My bcc will compile it to .asm in 2.2 seconds, but I need to fix the
> problem with its assembler to complete it.
>
> Testing for extreme programs and sorting out the problems that come up
> is kinda fun. Just keep me away from PE file formats.)
As I've said before, "fun" is a perfectly good reason, and trumps pretty
much anything else. Initialising a table using a huge function of
assignments is crazy and massively inefficient regardless of the
compiler, and regardless of whether you are talking about compile time
or run time, and code generators that make their tables this way should
be fixed. But if testing this stuff is fun, go for it. I've found a
lot weirder things fun. (And while I remain convinced that these tests
have no practical purpose, I have to admit having learned a little here.
Useless things, but Quite Interesting™ none the less.)
>
>> Oh, and just for fun I timed python reading these C files (with their
>> million lines) - 20 milliseconds. Reading the file and separating them
>> into lines is 70 milliseconds.
>
> Doesn't that make you wonder what the hell gcc is doing for 15 minutes,
> for processing the same input?
>
I have some idea.
gcc does not translate statements one by one as they come in. It builds
up trees in a variety of formats (it has at least two internal formats
used at different stages in compilation). It does many passes over
these, even with -O0, for analysis, checking, sorting and re-arranging
them. Register assignment involves working back and forth through these
trees. With code like this, especially on a relatively register-poor
architecture like x86 (x86-64 is better than 32-bit mode, but poor
compared to many other architectures), this amounts to a great deal of
effort for very little purpose. For more normal functions, it can make
a huge difference to the efficiency of the code.
I am actually quite surprised that the times scaled linearly with the
size of the functions, rather than worse.
>> A large clump of assignments, instead of an array initialisation, is a
>> /worse/ way to write the code in all reasonable interpretations of
>> "worse".
>
> If there was a better alternative then I would agree. But if using C as
> a backend target, then it may simply be more convenient to do it that
> way. Maybe the data tables aren't static. Maybe some elements could be
> runtime expressions.
>
Laziness on the part of the code generator is not an excuse, IMHO,
unless it is only designed to handle small and limited cases.
> So long as its valid C (and there is a LOT worse C written using
> macros), then that should be it.
>
If you didn't have your irrational prejudice against macros, your code
generator would be much simpler, resulting in neater generated code that
would compile to more efficient object code on a wider range of compilers.
> Some people /want/ to use C as a kind of portable assembler where you
> throw anything at it, including large blocks of the same thing, and
> expect it to just work.
>
Everything has its limits.
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web