Bart <bc@freeuk.com> writes:
>On 15/08/2023 13:45, David Brown wrote:
>> On 10/08/2023 17:18, Ben Bacarisse wrote:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>>> If working with Linux and you need -lm, then 'make prog' won't
>>>>>> work. That's
>>>>>> just a fact.
>>>>>
>>>>> 2+2 = 4.  That's just a fact.
>>>>
>>>> Indeed, and it is a fact for _any_ library containing optional
>>>> functionality
>>>> that is needed by the application.
>>>
>>> That's only true in a circular way.  Why are the math functions
>>> considered optional?  Why not, for example, consider the IO functions
>>> optional so that any program that includes <stdio.h> has to link with
>>> -lio?  (I know the history -- that's not what I'm asking.)
>>>
>>> There's even a division that could be justified by the standard.  Any
>>> program that uses functions not required in a freestanding
>>> implementation could be obliged to link with -lhosted, but requiring -lm
>>> is just a historical barnacle.
>>>
>>
>> I believe the "-lm" thing is, as you say, just historical.  C libraries
>> were split to reduce their size, and since the maths functions were
>> often unneeded but often depend on each other, that seemed a natural
>> split.  For many C libraries these days, libm.a is actually empty - it
>> exists solely so that "-lm" finds something if you use it.
>
>
>A test with dlopen/dlsym managed to find "sqrt" only from "libm.so.6".
>It coulldn't find it using "libc.so.6".

The 'nm' (namelist) command is quicker.

$ nm /usr/lib64/libc.so.6 | grep " [tT] " | wc -l
4573

So there are 4573 functions available in libc.so.6.

$ nm /usr/lib64/libc.so.6 | grep -i sqrt
$

On this implementation (fedora core), sqrt is not part of libc.

$ nm /usr/lib64/libm.so.6 | grep -i sqrt
0000003a4f62a060 t __csqrt
0000003a4f637ae0 t __csqrtf
0000003a4f642270 t __csqrtl
0000003a4f6169e0 t __ieee754_sqrt
0000003a4f630690 t __ieee754_sqrtf
0000003a4f63c530 t __ieee754_sqrtl
0000003a4f648f10 t __mpsqrt
0000003a4f65f810 t __mpsqrt_fma4
0000003a4f6add00 r __mpsqrt_mp
0000003a4f6270a0 t __sqrt
0000003a4f6169e0 T __sqrt_finite
0000003a4f634900 t __sqrtf
0000003a4f630690 T __sqrtf_finite
0000003a4f63f590 t __sqrtl
0000003a4f63c530 T __sqrtl_finite
0000003a4f62a060 W csqrt
0000003a4f637ae0 W csqrtf
0000003a4f642270 W csqrtl
0000003a4f6270a0 W sqrt
0000003a4f68e220 r sqrt_2.2994
0000003a4f68e220 r sqrt_2.3297
0000003a4f68e220 r sqrt_2.3533
0000003a4f634900 W sqrtf
0000003a4f63f590 W sqrtl

And David did say "many", not all.

David Brown <david.brown@hesbynett.no> writes:
> On 09/08/2023 19:18, Kaz Kylheku wrote:
>> I can't find clear references on this topic, but somehow, I seem to be
>> carrying an old impression from somewhere that the use of the diaeresis
>> for native words is just something that became fashinable in the 1800's.
>>
>> I.e. it's not simply archaic, but a revival of a passing Victorian
>> era fad.
>
> Yes, I think that is correct. But "naïve" is not a native English
> word - it came from the French, complete with accent.

Which is precisely why you shouldn't use it when communicating in
English, which has the word "naive" that performs exactly the same
task at least as adequately.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

On 15/08/2023 15:34, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 13/08/2023 18:02, Scott Lurndal wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 11/08/2023 12:17, Bart wrote:
>>>>> On 11/08/2023 07:43, David Brown wrote:
>>>
>>>>> Look, just do things your way, and let others use their own approaches.
>>>>> I've actually been doing this stuff for longer than you.
>>>>>
>>>>
>>>> Longer does not mean better. Often it means set in your ways, and
>>>> unwilling to look at alternatives.
>>>
>>> And I seriously doubt the "longer than you" bit.
>>
>> Bart /has/ been programming for longer than me - I've only been at it
>> for a little over 40 years.
>>
>
> Ah, 47 for me. I don't recall Bart posting his history.

47 years also since I first sat in front of a terminal and wrote code,
and I wasn't that young.

I couldn't do so from age 10, since then a computer probably cost 200
times as much as a house.

On 15/08/2023 16:51, Phil Carmody wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 09/08/2023 19:18, Kaz Kylheku wrote:
>>> I can't find clear references on this topic, but somehow, I seem to be
>>> carrying an old impression from somewhere that the use of the diaeresis
>>> for native words is just something that became fashinable in the 1800's.
>>>
>>> I.e. it's not simply archaic, but a revival of a passing Victorian
>>> era fad.
>>
>> Yes, I think that is correct. But "naïve" is not a native English
>> word - it came from the French, complete with accent.
>
> Which is precisely why you shouldn't use it when communicating in
> English, which has the word "naive" that performs exactly the same
> task at least as adequately.
>

"naïve" came from the French, and joined English - just like "café" and
a number of other words. It is absolutely fine to write "naïve" in
English, and I would expect anyone to be happy seeing it spelt that way
(baring issues with fonts). Equally, however, I would expect people to
be happy with "naive", and it would be wrong to suggest that either of
them is incorrectly spelt. The only time I would consider it
particularly important would be if the word were used multiple times in
the same document - then consistency should be the guiding factor.

Sometimes such foreign words keep their accents when merged into
English, sometimes the accents disappear over time. Sometimes they are
commonly written in italics to emphasise that they are not "native" -
but since English has accumulated words from all sorts of languages over
time, I think it is at best a question of time and common usage before a
word becomes "native".

These words are often called "loanwords", but we've kept them in
English, and are not giving them back :-)

On 15/08/2023 16:33, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 14/08/2023 18:06, Kaz Kylheku wrote:
>>> On 2023-08-14, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>>> On 2023-08-13, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>>> Bart <bc@freeuk.com> writes:
>>>>>>> On 13/08/2023 17:02, Scott Lurndal wrote:
>>>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>>>> On 12/08/2023 13:12, Bart wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Suppose you dispensed with all that dependency stuff; how long would it
>>>>>>>>>> take to build such a project? Say compared with just compiling one module.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That particular project takes a minute and a half to compile on my
>>>>>>>>> laptop (it's faster on my main machine). It's 373 compilations, perhaps
>>>>>>>>> 40% of it C++. Too long for convenience.
>>>>>>>>
>>>>>>>> My current project takes well over an hour to build on a single-core
>>>>>>>> system. With 32 cores and parallel make (-j32), that's reduced to
>>>>>>>> less than ten minutes
>>>>>>>
>>>>>>> You don't get a 32x speedup then?
>>>>>>
>>>>>> Compiler workloads are generally I/O bound.
>>>>>
>>>>> Not really. E.g. if you use ccache, and everything is a hit,
>>>>> it's "lightning fast" just to copy the .o files from the cache.
>>>>
>>>> We've used ccache, and had enough problems with it that we
>>>> abandoned it.
>>>
>>> For my purposes, I'm not running into the problem; ccache
>>> is working.
>>>
>>> Subtly broken or not, for the present purposes, it shows that two orders
>>> of magnitude of run-time can get saved by hashing the translation unit
>>> and just copying canned .o files.
>>
>> I use ccache myself, and have not seen any problems with it. (I disable
>> it when doing timings posted here.)
>
> The issues we saw were related to different users compiling with
> different compilation flags or optimization levels (the Ccache was
> shared by a hundred users). For the cases where the users were
> simply compiling the code it worked fine. For the developers actually
> developing the code, it caused issues when the developers modified
> debugging defines or the optimization level and tried to link with
> cached objects with different configurations.

ccache uses hashes from the complete command line, including flags, as
well as a hash of the entire pre-processed source code. That should not
be an issue. (At least, that's the case for ccache now - maybe you are
talking about long ago.)

What /might/ be an issue is slightly different versions of tools. I
would normally expect local ccaches on users' machines, rather than a
shared cache.

>
> In any case, we use dependency checking which limits recompilation
> to the files made obsolete by changes to source or header files.
>

Indeed.

>
>> There's a famous article somewhere titled "Recursive make considered
>> harmful".
>
>
> I've read it many times and found it not very compelling. Even
> linux uses recursive make sucessfully, and pretty much every project
> I've worked on over the last four decades (from Unixware to my
> current large project) use recursive makefiles without running
> into the issues in the article.
>

As long as you are careful, recursive make can work fine - but it does
introduce new ways to get things wrong.

>
>
>
>> I just make my binary depend on the object files matching
>> every source file in all the subdirectories, and let make sort it all
>> out (in parallel, though I don't have as many cores as Scott).
>
> It's a really nice two socket xeon system, to be sure :-).

I bet you have one of the Zen4 EPYC processors on your Christmas list!

On 15/08/2023 16:34, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 13/08/2023 18:02, Scott Lurndal wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 11/08/2023 12:17, Bart wrote:
>>>>> On 11/08/2023 07:43, David Brown wrote:
>>>
>>>>> Look, just do things your way, and let others use their own approaches.
>>>>> I've actually been doing this stuff for longer than you.
>>>>>
>>>>
>>>> Longer does not mean better. Often it means set in your ways, and
>>>> unwilling to look at alternatives.
>>>
>>> And I seriously doubt the "longer than you" bit.
>>
>> Bart /has/ been programming for longer than me - I've only been at it
>> for a little over 40 years.
>>
>
> Ah, 47 for me. I don't recall Bart posting his history.

He has talked about programming in Algol, but I don't know exactly when.

On 2023-08-15, Scott Lurndal <scott@slp53.sl.home> wrote:
> David Brown <david.brown@hesbynett.no> writes:
>>There's a famous article somewhere titled "Recursive make considered
>>harmful".
>
>
> I've read it many times and found it not very compelling. Even
> linux uses recursive make sucessfully, and pretty much every project
> I've worked on over the last four decades (from Unixware to my
> current large project) use recursive makefiles without running
> into the issues in the article.

The Linux build system has certain recursive make invocations, but does
not recursively invoke make in every subdirectory; it has one big
graph for the whole tree, consisting of including sub-makefiles.

For instance and out-of-tree module build will set some variables
and recursively redirect to the kernel tree with $(MAKE) -C <path>.
So, okay, that's a kind of recursion.

Top-level make re-invocation trick don't amount to the the main
"payload" build being recursive.

A recursive make system needs to execute numerous nested make
invocations in numerous directories in order to discover all the
targets that need to be built.

Maybe that hurts less when that can be parallelized? Or
is even faster?

The thing is that the size of the tree and the number of rules
doesn't change whether subtrees are handled by separate make
invocations or not. So it's mainly the overhead of the invocations
that is the problem.

The same amount of Makefile material has to be parsed either way.

A non-recursive Makefile system like described in that paper has
the disadvantage that /reading/ the Makefile material isn't
parallelizable, only /executing/ the rules A single process has to scan
the entire tree of sub-Makefiles before dispatching a build; only that
build is then parallel.

A recursive system can dispatch the sub-makes in parallel, using
multiple cores to read their respective sections of the rule
tree in parallel.

Thus, recursive make, even if Harful, could potentially be faster,
if the project tree is so large that scanning the makefile
material causes a noticeable delay in dispatching an incremental
build.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-15, Phil Carmody <pc+usenet@asdf.org> wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 09/08/2023 19:18, Kaz Kylheku wrote:
>>> I can't find clear references on this topic, but somehow, I seem to be
>>> carrying an old impression from somewhere that the use of the diaeresis
>>> for native words is just something that became fashinable in the 1800's.
>>>
>>> I.e. it's not simply archaic, but a revival of a passing Victorian
>>> era fad.
>>
>> Yes, I think that is correct. But "naïve" is not a native English
>> word - it came from the French, complete with accent.
>
> Which is precisely why you shouldn't use it when communicating in
> English, which has the word "naive" that performs exactly the same
> task at least as adequately.

Bingo! "naïve" did not /come/ from French, it /is/ French!

The word that came from French is "naive".

Just like the word that came into English from Japanese is "futon".

Whereas the related word "布団" did not come into English.

It all makes a 団 of sense; when you think about it this way.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

David Brown <david.brown@hesbynett.no> writes:
>On 15/08/2023 16:33, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 14/08/2023 18:06, Kaz Kylheku wrote:
>>>> On 2023-08-14, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>>>> On 2023-08-13, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>>>> Bart <bc@freeuk.com> writes:
>>>>>>>> On 13/08/2023 17:02, Scott Lurndal wrote:
>>>>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>>>>> On 12/08/2023 13:12, Bart wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Suppose you dispensed with all that dependency stuff; how long would it
>>>>>>>>>>> take to build such a project? Say compared with just compiling one module.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That particular project takes a minute and a half to compile on my
>>>>>>>>>> laptop (it's faster on my main machine). It's 373 compilations, perhaps
>>>>>>>>>> 40% of it C++. Too long for convenience.
>>>>>>>>>
>>>>>>>>> My current project takes well over an hour to build on a single-core
>>>>>>>>> system. With 32 cores and parallel make (-j32), that's reduced to
>>>>>>>>> less than ten minutes
>>>>>>>>
>>>>>>>> You don't get a 32x speedup then?
>>>>>>>
>>>>>>> Compiler workloads are generally I/O bound.
>>>>>>
>>>>>> Not really. E.g. if you use ccache, and everything is a hit,
>>>>>> it's "lightning fast" just to copy the .o files from the cache.
>>>>>
>>>>> We've used ccache, and had enough problems with it that we
>>>>> abandoned it.
>>>>
>>>> For my purposes, I'm not running into the problem; ccache
>>>> is working.
>>>>
>>>> Subtly broken or not, for the present purposes, it shows that two orders
>>>> of magnitude of run-time can get saved by hashing the translation unit
>>>> and just copying canned .o files.
>>>
>>> I use ccache myself, and have not seen any problems with it. (I disable
>>> it when doing timings posted here.)
>>
>> The issues we saw were related to different users compiling with
>> different compilation flags or optimization levels (the Ccache was
>> shared by a hundred users). For the cases where the users were
>> simply compiling the code it worked fine. For the developers actually
>> developing the code, it caused issues when the developers modified
>> debugging defines or the optimization level and tried to link with
>> cached objects with different configurations.
>
>ccache uses hashes from the complete command line, including flags, as
>well as a hash of the entire pre-processed source code. That should not
>be an issue. (At least, that's the case for ccache now - maybe you are
>talking about long ago.)

yes, this was a decade ago using, what was at the time, an older
version of ccache.

>
>What /might/ be an issue is slightly different versions of tools. I
>would normally expect local ccaches on users' machines, rather than a
>shared cache.

Ah, but in the RTL development environment, there are no local disks
other than the root disk since they're part of a grid and the system
on which the compile happens changes from run to run. It's all on
NFS.

The RTL team runs thousands of random simulations 24x7, and each
simulation compiles the RTL and supporting assets (e.g. the C++
golden model), leveraging the common ccache.

>>> I just make my binary depend on the object files matching
>>> every source file in all the subdirectories, and let make sort it all
>>> out (in parallel, though I don't have as many cores as Scott).
>>
>> It's a really nice two socket xeon system, to be sure :-).
>
>I bet you have one of the Zen4 EPYC processors on your Christmas list!

We've several options in mind for the next set of build machines :-)

On 2023-08-15, David Brown <david.brown@hesbynett.no> wrote:
> On 15/08/2023 16:33, Scott Lurndal wrote:
>> The issues we saw were related to different users compiling with
>> different compilation flags or optimization levels (the Ccache was
>> shared by a hundred users). For the cases where the users were
>> simply compiling the code it worked fine. For the developers actually
>> developing the code, it caused issues when the developers modified
>> debugging defines or the optimization level and tried to link with
>> cached objects with different configurations.
>
> ccache uses hashes from the complete command line, including flags, as
> well as a hash of the entire pre-processed source code. That should not
> be an issue. (At least, that's the case for ccache now - maybe you are
> talking about long ago.)

Speaking of ccache long ago, in 2006 I posted some patches for ccache.

https://www.mail-archive.com/ccache@lists.samba.org/msg00086.html

One of them is multiple-caches: this makes ccache look in more than
one cache for a hit. So you can have a local cache on your node only,
but fall back one a shared one, too.

Local builds don't have to pollute the shared cache, but can read
from it.

I think they didn't merge it. Someone was asking for it in 2016:

https://lists.samba.org/archive/ccache/2016q2/001444.html

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

David Brown <david.brown@hesbynett.no> writes:
>On 15/08/2023 16:34, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 13/08/2023 18:02, Scott Lurndal wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> On 11/08/2023 12:17, Bart wrote:
>>>>>> On 11/08/2023 07:43, David Brown wrote:
>>>>
>>>>>> Look, just do things your way, and let others use their own approaches.
>>>>>> I've actually been doing this stuff for longer than you.
>>>>>>
>>>>>
>>>>> Longer does not mean better. Often it means set in your ways, and
>>>>> unwilling to look at alternatives.
>>>>
>>>> And I seriously doubt the "longer than you" bit.
>>>
>>> Bart /has/ been programming for longer than me - I've only been at it
>>> for a little over 40 years.
>>>
>>
>> Ah, 47 for me. I don't recall Bart posting his history.
>
>He has talked about programming in Algol, but I don't know exactly when.

There's still a significant base of Unisys (nee Burroughs) systems in production
and Algol is the primary systems programming language for those systems.

The MCP is written in a custom flavor of Algol.

On 2023-08-15, David Brown <david.brown@hesbynett.no> wrote:
> On 15/08/2023 16:51, Phil Carmody wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 09/08/2023 19:18, Kaz Kylheku wrote:
>>>> I can't find clear references on this topic, but somehow, I seem to be
>>>> carrying an old impression from somewhere that the use of the diaeresis
>>>> for native words is just something that became fashinable in the 1800's.
>>>>
>>>> I.e. it's not simply archaic, but a revival of a passing Victorian
>>>> era fad.
>>>
>>> Yes, I think that is correct. But "naïve" is not a native English
>>> word - it came from the French, complete with accent.
>>
>> Which is precisely why you shouldn't use it when communicating in
>> English, which has the word "naive" that performs exactly the same
>> task at least as adequately.
>>
>
>
> "naïve" came from the French, and joined English - just like "café" and
> a number of other words.

In so doing, it became "naive". End of story.

Just like how 神風 became "kamikaze" when it came into English.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>> [...]
>>>
>>>>> Yes, C++ calls them literals. But that site does use the same
>>>>> terminology as the C standard when talking about C:
>>>>>
>>>>> https://en.cppreference.com/w/c/language/integer_constant
>>>>>
>>>>> I prefer C++'s usage, since "integer constant" can be so easily
>>>>> confused for "integer constant expression".
>>>>
>>>> Using the same term for both suggests a false equivalence, and
>>>> also is ahistorical. The two kinds of entities are fundamentally
>>>> different: constants denote values, literals denote objects.
>>>> Constants, like mathematical constants, always denote the same
>>>> value; literals denote different objects at different times or
>>>> places, even if the values used to produce a given literal are
>>>> always the same, which they need not be. The distinctions are
>>>> too important to gloss over by using a common term for both.
>>>
>>> When you say that "literals denote objects", are you referring
>>> specifically to the way C uses the terms "string literal" and
>>> "compound literal"?
>>>
>>> I haven't done an exhaustive search, but every language other than
>>> C whose documentation I've just checked (C++, Ada, Perl, Python,
>>> Go, Java) calls 42 an integer literal and "foo" a string literal.
>>> C is a bit of an outlier in callling 42 an integer constant.
>>>
>>> I suggest that the fact that C uses "constant" for tokens that
>>> refer to values and "literal" (string or compound) for constructs
>>> that refer to anonymous objects was an arbitrary choice, and the
>>> distinction you mention is not nearly as fundamental as you
>>> suggest it is.
>>>
>>> I do prefer to use the term "integer constant" when discussing C,
>>> but the phrase "integer literal" is (a) correct in most other
>>> languages and (b) perfectly clear. It wouldn't occur to me that
>>> "integer literal" implies something that refers to an object.
>>
>> The word literal, used as a noun when describing programming
>> languages, came into vogue sometime after it became common to
>> specify language syntax by using a formal grammar (usually
>> expressed in some variation of Backus-Naur Form); roughly the
>> 1970s timeframe. A typical usage would be for "literal" to be
>> synonymous with "terminal symbol", or perhaps with just a subset
>> of terminal symbols, as used in the rules of grammar. In some
>> cases the words "constant" and "literal" were used more or less
>> interchangeably.
>>
>> A good decade earlier, however, the word literal was used in a
>> somewhat different programming language context, not as part of
>> describing a language but as an element of the language. The
>> assembly language for IBM System/360 had constants, both ordinary
>> numeric and character constants, and symbolic constants (defined
>> with EQU). Constants could be used as direct operands for some
>> instructions, depending on the particulars of the instruction and
>> for which operand, and represented values encoded directly in the
>> instruction. Distinct from constants there were also /literals/,
>> a distinct category of operand that produced the address of an
>> initialized anonymous region of memory. Here are two example
>> lines of assembly, to illustrate the difference:
>>
>> OI VAL+2,X'F0'
>> C 3,=F'1000'
>>
>> In the first line, there are two constants, 2 and X'F0'. These
>> tokens are numerical quantities that are used directly in the
>> generated instruction. (In the case of the constant 2 the value
>> is added to the address VAL, and it is the sum that is used to
>> produce the bytes of the instruction, but the key property is
>> that the value 2 participates locally, and not remotely.)
>>
>> The second line has a constant 3 and a literal =F'1000'. Like in
>> the first line, the value 3 is used directly in the generated
>> instruction. The literal =F'1000' is not used directly. Instead,
>> the assembler keeps track of literals used in the program, and
>> uses them to initialize areas of memory elsewhere in the program.
>> A use of a literal, such as the =F'1000' here, results in the
>> address of the memory area reserved for the value of the literal.
>> (There are some further details about literals, such as literal
>> pools and the LTORG directive, that I won't explain because those
>> details are not important to the discussion.)
>>
>> Note the parallels between how these terms are used in assembly
>> language and in C. Constants are used to generate code but appear
>> only implicitly; literals always occupy areas of memory (objects)
>> and use of a literal causes its address (lvalue) to be part of a
>> generated instruction. The distinction between constants and
>> literals is primarily a semantic distinction, not a syntactic one.
>>
>> Besides being more historically faithful, having two different
>> terms provides a useful semantic distinction that would disappear
>> if the term "literal" were used for both concepts.
>>
>>
>>>> Given a choice between the level of confusion seen in the C++
>>>> standard and the level of confusion seen in the C standard ("integer
>>>> constant" and "integer constant expression" is confusing? really?)
>>>> I'm happy to be on the side of C's choice any day of the week and
>>>> twice on Sunday. Please cast my vote to continue using the terms
>>>> "constant" and "literal" as they are used in the C standard.
>>>
>>> I use those terms simply because that's how they're used in the C
>>> standard.
>>
>> Obviously it's a good idea to use terminology in the C standard
>> when talking about the C language. My point though is that the
>> terminology used in the C standard is a better choice both
>> historically and semantically.
>
> Ok, that's some interesting history -- but I've never heard of
> anything other than IBM System/360 assembly language (and C) that
> makes that particular distinction. Most programmers these days
> (myself included) are not more than vaguely familiar with
> System/360.

I have seen "literal" used in the descriptions of other high level
languages in much the same sense that it is used in C and in 360
Assembly. I don't remember where and haven't made an effort to
track them down.

> The distinction you suggest never occurred to me until you brought
> it up here. (The term "string literal" appears to have been
> introduced in K&R1, 1978; earlier documents use the term "string".
> All C documents I've checked back to 1975 refer to integer,
> character, and floating constants as "constants". B did the same.
> BCPL used the term "string constant".)
>
> Do you have other examples, or evidence that the distinction
> between "literals" and "constants" has been common?

I think this question misses the point of my comments. The word
"constant" seems reasonable to me for the sorts of things that C
calls constants; maybe another word would be okay, I haven't
really thought about it. My point though is not that "constant" is
right but that "literal" is wrong, both because it is ahistorical
and because it hides an important semantic distinction.

Furthermore, using "literal" for both constants and literals is bad
in another way, because the secondary meaning of "literal" had to
do with a lexical property (that "literals" correspond to terminal
symbols), but that property is lost when applied to things like
compound literals. I don't know if other languages do something
like that, but if they do then they are showing poor use of
language - in particular, copying the form of a word use without
understanding the underlying meaning. There's no reason to copy
bad examples, no matter how many of them there are.

David Brown <david.brown@hesbynett.no> writes:
> On 15/08/2023 16:51, Phil Carmody wrote:
>> David Brown <david.brown@hesbynett.no> writes:

>>> But "naïve" is not a native English
>>> word

> It is absolutely fine to write "naïve"
> in English

You're suffering cognitive dissonance.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

A postscript to my recent posting...

Perusing the C++ standard, I stumbled on this note:

Note: A literal type is one for which it might be possible
to create an object within a constant expression. It is not
a guarantee that it is possible to create such an object,
nor is it a guarantee that any object of that type will be
usable in a constant expression. --end note

No point to make, I just thought it's amusing.

wtorek, 15 sierpnia 2023 o 15:26:23 UTC+2 Malcolm McLean napisał(a):
> Most big processors have a hardware square root function. So I would hope
> compilers would inline calls rather than use a library.

i think to use this there should be some new calling convention to put in
declarations/header like
__hardware double sqrt(double);

(may be bester looking word)

btw the risc vs cisc 'discussion' is still valid imo..
is valid for example here becouse such things like sin, sqrt etc you may
count by using 'series' (or how it is called in english) with basic arithmetic)..
which is risc solution with this advantage you may chose yourself how many bits of precision you need (sometimes with simpel division you also dont need 50
bits but just like 10 or something..though i dont know if division is to count by series too)

cisc in turn can be eral optimisation..and if cisc work im not against it (though it better should be somewhat elegant and real usable...more interesting it would be to found "cisc" cases which would improve general coding for some big/notable factor liek 50% or something though today memory bandwidth is probably total bottleneck not the cpu (assuming memopry bandwidth is not a cpu problem, as i dont know if it is ram pieces or cpu problem)

this thread stopped ad 968 messages, maybe add yet some to reach 1000?