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 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-22 23:14 +0000 |
| Message-ID | <gtN1E.114711$Ur2.9009@fx14.am4> |
| In reply to | #140095 |
On 22/01/2019 22:02, David Brown wrote:
> On 22/01/2019 18:30, Bart wrote:
>> Sometimes the data needs to be embedded in the source code.
> 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.
(In my interpreted language I sometimes write stuff like this:
zipfile := strinclude "/m/zip.exe"
'strinclude' embeds the contents of any file, binary or text, as a
string constant, and here assigns that to a variable (The purpose of the
above was to install zip.exe on any system where it wasn't present.)
In the compiled language, this only works for text files (as strings
can't have embedded zeros), but it ought to work with html:
ichar index_html = strinclude "index.html"
(Here it's important not to use 'const index_html = ...' otherwise the
string constant is duplicated for each use. When translating to C, some
compilers already balk at long string constants.))
>> 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.
It's 5.1.0. It must have switched from 8.1 at some point (I don't like
the way the latter messes with my console colours).
8.1 is much better and completes this test in 50 seconds (assigning to a
table of a half a million strings one at a time, so I'm not sure it's
the same as yours).
Now I'll have to repeat some tests to give fairer results in my link.
But at least it means someone does notice these problems and fixes them.
> 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 have an idea for a new -O-1 optimisation setting for gcc, one below
-O0. With -O-1, it just runs an embedded version of Tiny C. Now you have
the advantage of much fast compilation to compensate for slower code.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-22 15:45 -0800 |
| Message-ID | <lny37c1ckj.fsf@kst-u.example.com> |
| In reply to | #140098 |
Bart <bc@freeuk.com> writes:
> On 22/01/2019 22:02, David Brown wrote:
[...
>> What gcc version? I had no hints of memory issues with my testing with
>> gcc 7 and gcc 8. It just took time.
>
> It's 5.1.0. It must have switched from 8.1 at some point (I don't like
> the way the latter messes with my console colours).
You must be aware that gcc has nothing to do with your console
colors. You probably installed some IDE that includes gcc as a
component, and the IDE did something to your console colors (and
would probably allow you to customize them in any way you like).
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-01-22 17:57 -0600 |
| Message-ID | <28bf4et4lma5gql12hoecja40gebad83d1@4ax.com> |
| In reply to | #140099 |
On Tue, 22 Jan 2019 15:45:32 -0800, Keith Thompson <kst-u@mib.org> wrote: >Bart <bc@freeuk.com> writes: >> On 22/01/2019 22:02, David Brown wrote: >[... >>> What gcc version? I had no hints of memory issues with my testing with >>> gcc 7 and gcc 8. It just took time. >> >> It's 5.1.0. It must have switched from 8.1 at some point (I don't like >> the way the latter messes with my console colours). > >You must be aware that gcc has nothing to do with your console >colors. You probably installed some IDE that includes gcc as a >component, and the IDE did something to your console colors (and >would probably allow you to customize them in any way you like). Doesn't gcc put ANSI color control sequences in error messages if -fdiagnostics-color is in effect? That may not be the default for all installations. Since gcc 5, or there abouts, I think.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-22 16:36 -0800 |
| Message-ID | <lntvi01a81.fsf@kst-u.example.com> |
| In reply to | #140101 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Tue, 22 Jan 2019 15:45:32 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
>
>>Bart <bc@freeuk.com> writes:
>>> On 22/01/2019 22:02, David Brown wrote:
>>[...
>>>> What gcc version? I had no hints of memory issues with my testing with
>>>> gcc 7 and gcc 8. It just took time.
>>>
>>> It's 5.1.0. It must have switched from 8.1 at some point (I don't like
>>> the way the latter messes with my console colours).
>>
>>You must be aware that gcc has nothing to do with your console
>>colors. You probably installed some IDE that includes gcc as a
>>component, and the IDE did something to your console colors (and
>>would probably allow you to customize them in any way you like).
>
> Doesn't gcc put ANSI color control sequences in error messages if
> -fdiagnostics-color is in effect? That may not be the default for all
> installations. Since gcc 5, or there abouts, I think.
Yes, it does. I knew it did highlighting, but I didn't realize it
used colors (since I've disabled colors in my terminal emulator).
I don't know whether that's what Bart is referring to.
You can turn off the highlighting using the "-fno-diagnostics-color"
command-line option or by setting the GCC_COLORS environment variable
to the empty string.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-23 01:37 +0000 |
| Message-ID | <UzP1E.78379$nC1.49911@fx04.am4> |
| In reply to | #140099 |
On 22/01/2019 23:45, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 22/01/2019 22:02, David Brown wrote: > [... >>> What gcc version? I had no hints of memory issues with my testing with >>> gcc 7 and gcc 8. It just took time. >> >> It's 5.1.0. It must have switched from 8.1 at some point (I don't like >> the way the latter messes with my console colours). > > You must be aware that gcc has nothing to do with your console > colors. You probably installed some IDE that includes gcc as a > component, and the IDE did something to your console colors (and > would probably allow you to customize them in any way you like). It's the only program that does this. It uses coloured text highlighting for warnings and errors. It also sets the background colour. When it's finished, it doesn't restore the original colours. (Some of my own console apps do the same, but they're the colours I want. Also they are proper interactive colour console applications not just scrolling teletype programs like a compiler.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-22 18:53 -0800 |
| Message-ID | <lnpnso13vx.fsf@kst-u.example.com> |
| In reply to | #140103 |
Bart <bc@freeuk.com> writes:
> On 22/01/2019 23:45, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 22/01/2019 22:02, David Brown wrote:
>> [...
>>>> What gcc version? I had no hints of memory issues with my testing with
>>>> gcc 7 and gcc 8. It just took time.
>>>
>>> It's 5.1.0. It must have switched from 8.1 at some point (I don't like
>>> the way the latter messes with my console colours).
>>
>> You must be aware that gcc has nothing to do with your console
>> colors. You probably installed some IDE that includes gcc as a
>> component, and the IDE did something to your console colors (and
>> would probably allow you to customize them in any way you like).
>
> It's the only program that does this. It uses coloured text highlighting
> for warnings and errors. It also sets the background colour.
>
> When it's finished, it doesn't restore the original colours.
>
> (Some of my own console apps do the same, but they're the colours I
> want. Also they are proper interactive colour console applications not
> just scrolling teletype programs like a compiler.)
Yes, that's something gcc does. Sorry about the confusion.
As I said elsewhere in this thread, there is a workaround.
(clang doesn't pay attention to the GCC_COLORS environment variable,
but it does recognize the -fno-color-diagnostics option.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-23 09:42 +0100 |
| Message-ID | <q299e9$fuu$1@dont-email.me> |
| In reply to | #140103 |
On 23/01/2019 02:37, Bart wrote: > On 22/01/2019 23:45, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >>> On 22/01/2019 22:02, David Brown wrote: >> [... >>>> What gcc version? I had no hints of memory issues with my testing with >>>> gcc 7 and gcc 8. It just took time. >>> >>> It's 5.1.0. It must have switched from 8.1 at some point (I don't like >>> the way the latter messes with my console colours). >> >> You must be aware that gcc has nothing to do with your console >> colors. You probably installed some IDE that includes gcc as a >> component, and the IDE did something to your console colors (and >> would probably allow you to customize them in any way you like). > > It's the only program that does this. It uses coloured text highlighting > for warnings and errors. It also sets the background colour. It is not the only program that does that - many *nix command line programs do that. "grep", for example, will highlight the search string in its output. Programs usually only do that if they detect support for colour in the terminal you are using (for example, if you redirect the output to a file or a pipe, colours are disabled). For example, if I want to know the gcc command line options regarding colour, I can type "gcc -h -v | grep color". Because of the way gcc prints the help lines with very long logical lines, there is quite a lot of output. But "grep" helpfully highlights the word "color" in the output, and makes it easy to see the information I want. So you can use -fdiagnostics-color=[never|always|auto] with gcc. "auto" is the default in newer gcc versions, and will use colour if the terminal appears to support it. "never" turns it off, "always" forces it on. > > When it's finished, it doesn't restore the original colours. This is going to depend on the terminal you are using. Windows command prompt might follow enough of the terminal standards to get some colours, but not enough to restore the originals properly. You could try a different terminal, such as the MSys2 terminal. The default colour settings for gcc do not change the background colours, so it might be a conflict between your gcc distribution and the terminal. Or maybe the gcc distribution you got changed the GCC_COLORS environmental variable to something weird. The slightly outdated MSys2/Mingw-64 gcc I have on my Windows machine (gcc 6.3) works fine with colours in a standard Windows terminal. If you can't get the colour working to your liking - or if you don't like colour - then set a global environment variable "GCC_COLORS" to a blank string to disable it. That will save you using a command line switch. > > (Some of my own console apps do the same, but they're the colours I > want. Also they are proper interactive colour console applications not > just scrolling teletype programs like a compiler.) A great many gcc users find the colouring and error highlighting helpful. That's why it is the default. But people have different needs and opinions, and so it is configurable.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-23 09:22 +0100 |
| Message-ID | <q2987s$9p1$1@dont-email.me> |
| In reply to | #140098 |
On 23/01/2019 00:14, Bart wrote:
> On 22/01/2019 22:02, David Brown wrote:
>> On 22/01/2019 18:30, Bart wrote:
>
>>> Sometimes the data needs to be embedded in the source code.
>
>> 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.
>
> (In my interpreted language I sometimes write stuff like this:
>
> zipfile := strinclude "/m/zip.exe"
>
> 'strinclude' embeds the contents of any file, binary or text, as a
> string constant, and here assigns that to a variable (The purpose of the
> above was to install zip.exe on any system where it wasn't present.)
>
> In the compiled language, this only works for text files (as strings
> can't have embedded zeros), but it ought to work with html:
Strings, including string literals, can have embedded zeros. But for
binary files, the addition of the terminating 0 at the end of the string
may be an issue.
>
> ichar index_html = strinclude "index.html"
>
Sure, it would be convenient to have this in the language. C does not
have this ability. (The gnu assembler does, so it would be possible to
make a macro that handles this via inline assembly in gcc - but I am
happy with my Python method as it is more flexible.)
> (Here it's important not to use 'const index_html = ...' otherwise the
> string constant is duplicated for each use. When translating to C, some
> compilers already balk at long string constants.))
That makes no sense whatsoever. Or are you talking about a limitation
in your own language for how you handle strings? "const" does not make
things duplicated in C.
Compilers may have trouble with long string constants. To be honest, I
can't remember why I used string constants in the code quoted - usually
my scripts generate code more like :
const uint8_t hiTable[256] = {
0x00, 0xc1, 0x81, 0x40, 0x01, 0xc0, 0x80, 0x41,
...
In the example I used first, the Python code was more complicated than
usual because it combined many files in different ways and pre-generated
some structures that got embedded in the C code as constant arrays.
>
>
>>> 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.
>
> It's 5.1.0. It must have switched from 8.1 at some point (I don't like
> the way the latter messes with my console colours).
>
> 8.1 is much better and completes this test in 50 seconds (assigning to a
> table of a half a million strings one at a time, so I'm not sure it's
> the same as yours).
OK. Well, we should both be pleased to see progress here.
>
> Now I'll have to repeat some tests to give fairer results in my link.
> But at least it means someone does notice these problems and fixes them.
I told you that before - I know of at least one bug report about
handling of long functions. But that is for realistic long functions
(the reporter was generating code for circuit simulations, I think),
rather than purely artificial ones.
>
>> 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 have an idea for a new -O-1 optimisation setting for gcc, one below
> -O0. With -O-1, it just runs an embedded version of Tiny C. Now you have
> the advantage of much fast compilation to compensate for slower code.
>
Feel free to propose it on the gcc mailing lists. You'll probably get
more polite responses than you risk here.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-01-23 08:52 -0500 |
| Message-ID | <q29rir$jr1$1@dont-email.me> |
| In reply to | #140107 |
On 1/23/19 03:22, David Brown wrote:
...
> Strings, including string literals, can have embedded zeros.
String literals can have embedded null characters:
"a\0b";
Arrays of character type can have embedded null characters:
char array[] = {'a', '\0', 'b', '\0'};
But strings cannot have embedded null characters, because they are, by
definition (7.1.1p1), terminated by the first null character. Both the
array and the string literal given above contain two non-overlapping
strings.
> ... But for
> binary files, the addition of the terminating 0 at the end of the string
> may be an issue.
Correct:
"A binary stream ... may, however, have an implementation-defined number
of null characters appended to the end of the stream."
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-23 15:13 +0100 |
| Message-ID | <q29sqq$s9h$1@dont-email.me> |
| In reply to | #140115 |
On 23/01/2019 14:52, James Kuyper wrote:
> On 1/23/19 03:22, David Brown wrote:
> ...
>> Strings, including string literals, can have embedded zeros.
>
> String literals can have embedded null characters:
> "a\0b";
> Arrays of character type can have embedded null characters:
> char array[] = {'a', '\0', 'b', '\0'};
>
> But strings cannot have embedded null characters, because they are, by
> definition (7.1.1p1), terminated by the first null character. Both the
> array and the string literal given above contain two non-overlapping
> strings.
>
Fair enough. No one can accuse the C committee of being careful about
consistency in defining their terms!
>> ... But for
>> binary files, the addition of the terminating 0 at the end of the string
>> may be an issue.
>
> Correct:
> "A binary stream ... may, however, have an implementation-defined number
> of null characters appended to the end of the stream."
>
That is for a C binary stream. I am talking about a binary file.
Adding extra nulls on the end will change the file. Whether that will
make a difference or not, depends entirely on the type of file and how
it is used.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-23 14:33 +0000 |
| Message-ID | <%W_1E.132876$IF1.28985@fx03.am4> |
| In reply to | #140107 |
On 23/01/2019 08:22, David Brown wrote:
> On 23/01/2019 00:14, Bart wrote:
[Embedding files as data]
>> In the compiled language, this only works for text files (as strings
>> can't have embedded zeros), but it ought to work with html:
>
> Strings, including string literals, can have embedded zeros. But for
> binary files, the addition of the terminating 0 at the end of the string
> may be an issue.
There are all sorts of problems with binary data, so that I only allow
text. There were also problems in the script language, but there I made
it work; the use of counted string types made it easier.
If I try this:
ichar words=strinclude "hello.exe"
(where hello.exe is a 2.5K file), and translate to C, I get:
static byte * t_words = (byte*)"MZ";
A three-character string (the third char with code 0x90 is not shown
here). Even if the translation includes all 2560 bytes using \xx codes
within the string, there still isn't a mechanism to to denote the length.
>> (Here it's important not to use 'const index_html = ...' otherwise the
>> string constant is duplicated for each use. When translating to C, some
>> compilers already balk at long string constants.))
>
> That makes no sense whatsoever. Or are you talking about a limitation
> in your own language for how you handle strings? "const" does not make
> things duplicated in C.
If I were to do:
const s = "abc"
print s,s,s
then "abc" is effectively repeated 3 times. (The C translation has three
lots of "abc" in the source)
With very long strings, you don't really want them duplicated as it can
increase the executable size significantly. (Maybe some C compilers will
detect identical string constants and only have one instance, but I
haven't looked into it.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-01-23 07:30 -0800 |
| Message-ID | <0cbcd6dc-59fb-4d03-adbd-09d06a2e59de@googlegroups.com> |
| In reply to | #140118 |
On Wednesday, January 23, 2019 at 9:33:38 AM UTC-5, Bart wrote:
> On 23/01/2019 08:22, David Brown wrote:
...
> >> (Here it's important not to use 'const index_html = ...' otherwise the
> >> string constant is duplicated for each use. When translating to C, some
> >> compilers already balk at long string constants.))
> >
> > That makes no sense whatsoever. Or are you talking about a limitation
> > in your own language for how you handle strings? "const" does not make
> > things duplicated in C.
>
> If I were to do:
> const s = "abc"
> print s,s,s
>
> then "abc" is effectively repeated 3 times. (The C translation has three
> lots of "abc" in the source)
So he's right - it is a limitation in your own language for how
you handle strings. That's a poor translation. Given your general
confusion about arrays and pointers, I'm not sure whether tha
declaration in your language should be translated to C as
const char *s = "abc";
or as
const char s[] = "abc";
but either way, the print statement should be translated to C
using something like the following:
printf("%s%s%s", s, s, s);
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-23 16:05 +0000 |
| Message-ID | <9h02E.76962$XD2.32484@fx10.am4> |
| In reply to | #140119 |
On 23/01/2019 15:30, James Kuyper wrote:
> On Wednesday, January 23, 2019 at 9:33:38 AM UTC-5, Bart wrote:
>> On 23/01/2019 08:22, David Brown wrote:
> ...
>>>> (Here it's important not to use 'const index_html = ...' otherwise the
>>>> string constant is duplicated for each use. When translating to C, some
>>>> compilers already balk at long string constants.))
>>>
>>> That makes no sense whatsoever. Or are you talking about a limitation
>>> in your own language for how you handle strings? "const" does not make
>>> things duplicated in C.
>>
>> If I were to do:
>> const s = "abc"
>> print s,s,s
>>
>> then "abc" is effectively repeated 3 times. (The C translation has three
>> lots of "abc" in the source)
>
> So he's right - it is a limitation in your own language for how
> you handle strings. That's a poor translation. Given your general
> confusion about arrays and pointers, I'm not sure whether tha
> declaration in your language should be translated to C as
> const char *s = "abc";
>
> or as
>
> const char s[] = "abc";
Neither applies; see below.
> but either way, the print statement should be translated to C
> using something like the following:
>
> printf("%s%s%s", s, s, s);
>
There is a problem with finding a general way of translating named
constants in one language to the equivalent in C, where it is necessary
to choose between #define, or enums or just showing the literal directly.
So the decision is made to just show literals which works for all types
that can follow 'const':
const pie = 2.71828
print pie,pie,pie # ('pi' is a built-in constant)
The generated C is ('print' adds item spacing):
printf("%f %f %f",(double)2.718280,(double)2.718280,
(double)2.718280);
The same logic applies to string constants. The idea of named constants
is that the effect should be the same as if you had just typed the
constant itself.
In the case of 'print s,s,s', the strings are combined into one when
translated to native code, but only because they are consecutive.
But the issue is a small one: multiple small identical strings, of the
kind that normally appear in source code, are not a problem.
It is only with very long strings imported from files that care is
needed, and only if you name a 'strinclude' rather than use it directly
in an expression.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-23 17:17 +0100 |
| Message-ID | <q2a438$aj2$1@dont-email.me> |
| In reply to | #140121 |
On 23/01/2019 17:05, Bart wrote:
> On 23/01/2019 15:30, James Kuyper wrote:
>> On Wednesday, January 23, 2019 at 9:33:38 AM UTC-5, Bart wrote:
>>> On 23/01/2019 08:22, David Brown wrote:
>> ...
>>>>> (Here it's important not to use 'const index_html = ...' otherwise the
>>>>> string constant is duplicated for each use. When translating to C,
>>>>> some
>>>>> compilers already balk at long string constants.))
>>>>
>>>> That makes no sense whatsoever. Or are you talking about a limitation
>>>> in your own language for how you handle strings? "const" does not make
>>>> things duplicated in C.
>>>
>>> If I were to do:
>>> const s = "abc"
>>> print s,s,s
>>>
>>> then "abc" is effectively repeated 3 times. (The C translation has three
>>> lots of "abc" in the source)
>>
>> So he's right - it is a limitation in your own language for how
>> you handle strings. That's a poor translation. Given your general
>> confusion about arrays and pointers, I'm not sure whether tha
>> declaration in your language should be translated to C as
>> const char *s = "abc";
>>
>> or as
>>
>> const char s[] = "abc";
>
> Neither applies; see below.
>
>> but either way, the print statement should be translated to C
>> using something like the following:
>>
>> printf("%s%s%s", s, s, s);
>>
>
> There is a problem with finding a general way of translating named
> constants in one language to the equivalent in C, where it is necessary
> to choose between #define, or enums or just showing the literal directly.
There is only a problem because you make it a problem - and you only do
that so that you can claim that C has a problem with constants.
Floating constants will only be used as floating point numbers. You can
translate them to "static const double pie = 1.234;" without trouble.
(I don't know how you declare data to be exported or local to a module
in your language - use "static" when possible.)
Strings will be either "const char * s = "Hello";", or "const char s[] =
"Hello";" - like James, I don't know which you would prefer.
That leaves integers. There are some cases where you might want to use
the integer constants in a way that "static const int x = 123;" in C
does not allow. The most practical choice, if you want a single
solution, is probably enum - "enum { x = 123 };".
>
> So the decision is made to just show literals which works for all types
> that can follow 'const':
>
> const pie = 2.71828
> print pie,pie,pie # ('pi' is a built-in constant)
>
> The generated C is ('print' adds item spacing):
>
> printf("%f %f %f",(double)2.718280,(double)2.718280,
> (double)2.718280);
>
So we are right - it is a limitation of your language or your design of
code generator.
> The same logic applies to string constants. The idea of named constants
> is that the effect should be the same as if you had just typed the
> constant itself.
>
> In the case of 'print s,s,s', the strings are combined into one when
> translated to native code, but only because they are consecutive.
>
> But the issue is a small one: multiple small identical strings, of the
> kind that normally appear in source code, are not a problem.
>
And they would be no issue at all with slightly smarter code generation,
or if you use a slightly smarter C compiler with slightly smarter
choices of flags (or a slightly smarter attitude towards conditional
compilation and pragmas).
> It is only with very long strings imported from files that care is
> needed, and only if you name a 'strinclude' rather than use it directly
> in an expression.
So don't use strings to implement your imports. At the very least,
don't use the same somewhat silly way to implement them.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-23 16:29 +0000 |
| Message-ID | <uD02E.189266$ux2.42806@fx25.am4> |
| In reply to | #140122 |
On 23/01/2019 16:17, David Brown wrote: > On 23/01/2019 17:05, Bart wrote: >> It is only with very long strings imported from files that care is >> needed, and only if you name a 'strinclude' rather than use it directly >> in an expression. > > So don't use strings to implement your imports. At the very least, > don't use the same somewhat silly way to implement them. You think it's silly? Here's a how I embed my C standard headers into the compiler; this is part of the source code: -------------------------- ichar h_assert = strinclude "headers/assert.h" ichar h_ctype = strinclude "headers/ctype.h" ichar h_errno = strinclude "headers/errno.h" ichar h_fenv = strinclude "headers/fenv.h" ichar h_float = strinclude "headers/float.h" ichar h_inttypes = strinclude "headers/inttypes.h" ichar h_stdint = strinclude "headers/stdint.h" ichar h_limits = strinclude "headers/limits.h" ichar h_locale = strinclude "headers/locale.h" ichar h__ansi = strinclude "headers/_ansi.h" ichar h_math = strinclude "headers/math.h" ichar h_setjmp = strinclude "headers/setjmp.h" ichar h_signal = strinclude "headers/signal.h" ichar h_stdarg = strinclude "headers/stdarg.h" ichar h_stdbool = strinclude "headers/stdbool.h" ichar h_stddef = strinclude "headers/stddef.h" ichar h_stdio = strinclude "headers/stdio.h" ichar h_stdlib = strinclude "headers/stdlib.h" ichar h__syslist = strinclude "headers/_syslist.h" ichar h_string = strinclude "headers/string.h" ichar h_time = strinclude "headers/time.h" ichar h_utime = strinclude "headers/utime.h" ichar h_unistd = strinclude "headers/unistd.h" ichar h_safelib = strinclude "headers/safelib.h" ichar h_wchar = strinclude "headers/wchar.h" ichar h_wctype = strinclude "headers/wctype.h" ichar h_systypes = strinclude "headers/sys/types.h" ichar h_sysstat = strinclude "headers/sys/stat.h" ichar h_systimeb = strinclude "headers/sys/timeb.h" ichar h_sysutime = strinclude "headers/sys/utime.h" ichar h_memory = strinclude "headers/memory.h" ichar h_windows = strinclude "headers/windows.h" ichar h_fcntl = strinclude "headers/fcntl.h" ichar h_io = strinclude "headers/io.h" ichar h_direct = strinclude "headers/direct.h" ichar h_process = strinclude "headers/process.h" ichar h_malloc = strinclude "headers/malloc.h" ichar h_bcc = strinclude "headers/bcc.h" ichar h_conio = strinclude "headers/conio.h" !ichar h_shellapi = strinclude "headers/shellapi.h" ichar h_windowsx = strinclude "headers/windowsx.h" --------------------- (Each is named and then is part of another table, because I disliked directly using strinclude inside another expression, which would eliminate the problem, which in turn is an issue with const-handling not text imports.) This allows the C compiler to exist as just one standalone executable file with no other dependencies. How would C achieve the same?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-23 22:04 +0100 |
| Message-ID | <q2aks7$pkt$1@dont-email.me> |
| In reply to | #140126 |
On 23/01/2019 17:29, Bart wrote: > On 23/01/2019 16:17, David Brown wrote: >> On 23/01/2019 17:05, Bart wrote: > >>> It is only with very long strings imported from files that care is >>> needed, and only if you name a 'strinclude' rather than use it directly >>> in an expression. >> >> So don't use strings to implement your imports. At the very least, >> don't use the same somewhat silly way to implement them. > > You think it's silly? Here's a how I embed my C standard headers into > the compiler; this is part of the source code: > > -------------------------- > ichar h_assert = strinclude "headers/assert.h" I don't know what you mean by this - and I'm not sure I want to. But clearly this is a special case. We were talking about binary files, for which strings is probably a silly way to implement them. > > (Each is named and then is part of another table, because I disliked > directly using strinclude inside another expression, which would > eliminate the problem, which in turn is an issue with const-handling not > text imports.) > > This allows the C compiler to exist as just one standalone executable > file with no other dependencies. > > How would C achieve the same? That question does not even make sense.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-23 21:50 +0000 |
| Message-ID | <xk52E.195573$Y32.38753@fx19.am4> |
| In reply to | #140132 |
On 23/01/2019 21:04, David Brown wrote:
> On 23/01/2019 17:29, Bart wrote:
>> On 23/01/2019 16:17, David Brown wrote:
>>> On 23/01/2019 17:05, Bart wrote:
>>
>>>> It is only with very long strings imported from files that care is
>>>> needed, and only if you name a 'strinclude' rather than use it directly
>>>> in an expression.
>>>
>>> So don't use strings to implement your imports. At the very least,
>>> don't use the same somewhat silly way to implement them.
>>
>> You think it's silly? Here's a how I embed my C standard headers into
>> the compiler; this is part of the source code:
>>
>> --------------------------
>> ichar h_assert = strinclude "headers/assert.h"
>
> I don't know what you mean by this - and I'm not sure I want to.
if the line was:
ichar h_hello = strinclude "hello.c"
then a C translation might be:
static byte * h_hello = (byte*)"#include <stdio.h>\r\n\r\nint
main(void) {\r\n printf(\"Hello, World!\\n\");\r\n}\r\n";
But
> clearly this is a special case. We were talking about binary files, for
> which strings is probably a silly way to implement them.
No, this bit was about avoiding the duplication of long strings
(specifically ones that represent the contents of a file).
>> How would C achieve the same?
>
> That question does not even make sense.
How do you painlessly embed files (text files for this example) into a C
source file so that they are represent as a string constant.
And in a way that, each time you compile the C file, it will use the
latest version of that text file.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-24 10:45 +0100 |
| Message-ID | <q2c1f8$kqv$1@dont-email.me> |
| In reply to | #140134 |
On 23/01/2019 22:50, Bart wrote:
> On 23/01/2019 21:04, David Brown wrote:
>> On 23/01/2019 17:29, Bart wrote:
>>> On 23/01/2019 16:17, David Brown wrote:
>>>> On 23/01/2019 17:05, Bart wrote:
>>>
>>>>> It is only with very long strings imported from files that care is
>>>>> needed, and only if you name a 'strinclude' rather than use it
>>>>> directly
>>>>> in an expression.
>>>>
>>>> So don't use strings to implement your imports. At the very least,
>>>> don't use the same somewhat silly way to implement them.
>>>
>>> You think it's silly? Here's a how I embed my C standard headers into
>>> the compiler; this is part of the source code:
>>>
>>> --------------------------
>>> ichar h_assert = strinclude "headers/assert.h"
>>
>> I don't know what you mean by this - and I'm not sure I want to.
>
> if the line was:
>
> ichar h_hello = strinclude "hello.c"
>
> then a C translation might be:
>
> static byte * h_hello = (byte*)"#include <stdio.h>\r\n\r\nint
> main(void) {\r\n printf(\"Hello, World!\\n\");\r\n}\r\n";
>
OK.
>
> But
>> clearly this is a special case. We were talking about binary files,
>> for which strings is probably a silly way to implement them.
>
> No, this bit was about avoiding the duplication of long strings
> (specifically ones that represent the contents of a file).
The C translation you have above has no duplication. It would be wiser
to use "static const byte * const h_hello", but there is not going to be
any duplications.
>
>>> How would C achieve the same?
>>
>> That question does not even make sense.
>
> How do you painlessly embed files (text files for this example) into a C
> source file so that they are represent as a string constant.
>
The C language has no direct support for that. But that's okay - it's
not the job of a programming language. I don't remember seeing any
other high-level language that supports this feature. (That does not
mean it is a bad idea at all - your language is a specialised one
tailored to your needs.)
For C, and any other languages, you do this via converters that are part
of your build process (that's what I do with my Python scripts),
linkers, other tools like "resource compilers", or compiler-specific
extensions.
Often you have particular purposes in mind for this sort of thing - for
example, if you are making a Windows executable, you'll want the icon
file to be embedded, but you want to do that in a particular
Windows-specific way, not as a general include.
For my own use, I often want to manipulate the file in some way -
perhaps include the file name as data, or generate CRC checks, or
include a whole directory of files. No language-based "include"
facility could handle that - a Python script called from "make" does so
easily.
GNU ld, the linker usually used with gcc, can also turn binary files
into object files with "ld -r -o object.o -b binary pic.jpg". I haven't
used this myself, so I am not familiar with the details.
But those sorts of things are specific to the compiler implementation
and other tools. My preference is actually much like yours - use a
program that generates the appropriate C code.
> And in a way that, each time you compile the C file, it will use the
> latest version of that text file.
Each time I compile my C file, I get the latest version of the files.
You are trying to solve a "problem" that was solved over forty years
ago. If your system is convenient for your uses, great. But don't make
the mistake of thinking it is special, or that your tools can do
something that others cannot, or that it makes your language more
capable than others. It makes it a little more convenient for some
cases - which is a good thing, but not a dramatic thing. And for the
type of file embedded I do, it would not help in any way.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-24 11:55 +0000 |
| Message-ID | <yIh2E.106094$UF1.91039@fx13.am4> |
| In reply to | #140146 |
On 24/01/2019 09:45, David Brown wrote:
> On 23/01/2019 22:50, Bart wrote:
>> How do you painlessly embed files (text files for this example) into a C
>> source file so that they are represent as a string constant.
>>
>
> The C language has no direct support for that. But that's okay - it's
> not the job of a programming language. I don't remember seeing any
> other high-level language that supports this feature. (That does not
> mean it is a bad idea at all - your language is a specialised one
> tailored to your needs.)
No, this is a general purpose requirement with a range of uses.
>> And in a way that, each time you compile the C file, it will use the
>> latest version of that text file.
>
> Each time I compile my C file, I get the latest version of the files.
> You are trying to solve a "problem" that was solved over forty years
> ago.
I mean the latest version of the file being embedded. If you rely on a
tool and a process to get the file into the C source, then you have to
run that process again before you can compile.
If your system is convenient for your uses, great. But don't make
> the mistake of thinking it is special, or that your tools can do
> something that others cannot, or that it makes your language more
> capable than others.
If this feature is rare, then I think it does make it more capable. (Not
even my idea, I think it came from something that BGB once said.)
It makes it a little more convenient for some
> cases - which is a good thing, but not a dramatic thing. And for the
> type of file embedded I do, it would not help in any way.
Why not? I mean if that feature was in C, to embed text or binary data,
what would be the problem with it?
(BTW I've just spent a pleasant 20 minutes adding 'strinclude' to my C
compiler. Here, the file name is in parentheses as it suits the language
better. This is a program that prints itself, and does it without
requiring that the source file exists at runtime:
#include <stdio.h>
int main(void) {
puts(strinclude(__FILE__));
}
In the sig are the two dozen lines of code that implements it. How does
that compare with using external scripts? In this test, it does not use
the same search algorithm as include files.)
--
(Not shown: two extra lines to declare 'kstrincludesym' and '"strinclude"')
when kstrincludesym then
p:=readstrinclude()
....
function readstrinclude:unit=
unit p
ichar text
lex()
checksymbol(lbracksym)
lex()
p:=readexpression()
checksymbol(rbracksym)
lex()
if p^.tag<>j_const or p^.mode<>trefchar then
serror("String const expected")
fi
text:=readfile(p^.svalue)
if not text then
serror_s("Can't read strinclude file: %s",p^.svalue)
fi
return createstringconstunit(text,strlen(text))
end
('readfile' does not do complex searching as is done with include files.
That would need the use of 'getsourcefile' which works a little
differently.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-24 13:58 +0100 |
| Message-ID | <q2ccpa$irf$1@dont-email.me> |
| In reply to | #140156 |
On 24/01/2019 12:55, Bart wrote:
> On 24/01/2019 09:45, David Brown wrote:
>> On 23/01/2019 22:50, Bart wrote:
>
>>> How do you painlessly embed files (text files for this example) into a C
>>> source file so that they are represent as a string constant.
>>>
>>
>> The C language has no direct support for that. But that's okay - it's
>> not the job of a programming language. I don't remember seeing any
>> other high-level language that supports this feature. (That does not
>> mean it is a bad idea at all - your language is a specialised one
>> tailored to your needs.)
>
> No, this is a general purpose requirement with a range of uses.
>
>>> And in a way that, each time you compile the C file, it will use the
>>> latest version of that text file.
>>
>> Each time I compile my C file, I get the latest version of the files.
>> You are trying to solve a "problem" that was solved over forty years
>> ago.
>
> I mean the latest version of the file being embedded. If you rely on a
> tool and a process to get the file into the C source, then you have to
> run that process again before you can compile.
>
Compiling my C code relies on dozens of tools - shells, OS's, editors,
compiler, assembler, linker, etc. I don't have to manually run extra
processes to make sure that the latest version of my files get included
- it happens automatically when I type "make" (or press "ctrl-B"), which
is a shorter and simpler command than you use to run your compiler.
People have been using tools since our ancestors climbed down from the
trees. I wonder if you'd complain that nails are a bad idea, because
they are sore to hammer in with your forehead.
> If your system is convenient for your uses, great. But don't make
>> the mistake of thinking it is special, or that your tools can do
>> something that others cannot, or that it makes your language more
>> capable than others.
>
> If this feature is rare, then I think it does make it more capable. (Not
> even my idea, I think it came from something that BGB once said.)
>
If it is rare, it is because few others think it is a useful feature -
or they think it is not worth the effort.
> It makes it a little more convenient for some
>> cases - which is a good thing, but not a dramatic thing. And for the
>> type of file embedded I do, it would not help in any way.
>
> Why not? I mean if that feature was in C, to embed text or binary data,
> what would be the problem with it?
>
It would not have the features I need. I have given examples of these
before, but let me try again. Sometimes I want to modify the file I
bring in. Perhaps I want to add extra information to it - the size, a
CRC check, a digital signature, some metainformation. Perhaps I want to
bring in a number of files - all the files in a directory, without
having to list them all manually. Perhaps i want to convert the files
in some way. Perhaps I don't want to include files at all, but just
generate some data tables that would be inefficient on the target
system. This is all simple when these files are read in with a
high-level language (I use Python - there are many alternatives) which
then generates appropriate C code. It means all this work is done at
build time, not at run time.
> (BTW I've just spent a pleasant 20 minutes adding 'strinclude' to my C
> compiler. Here, the file name is in parentheses as it suits the language
> better. This is a program that prints itself, and does it without
> requiring that the source file exists at runtime:
>
> #include <stdio.h>
>
> int main(void) {
> puts(strinclude(__FILE__));
> }
>
> In the sig are the two dozen lines of code that implements it. How does
> that compare with using external scripts? In this test, it does not use
> the same search algorithm as include files.)
>
It compares hopelessly with using external scripts, because it does not
do anything even vaguely like what I need.
If it does what /you/ need, then great. But it does not do what /I/ need.
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web