is there any standards that tell us how c code has to be compiled into
machine code
Aug 23 '08
82  2551 
Keith Thompson wrote:
Richard Heathfield <rj*@see.sig.invalidwrites:
Richard Tobin said:
In article <lp******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
In any case, correctness is far more important than speed.
Not always. For some purposes, as someone used to have in their
signature, "late answers are wrong answers".
Wrong answers are wrong answers, too. Getting them quicker doesn't make
them righter.
You're both right. Sometimes speed is simply part of the
requirements. (And sometimes it isn't.)
*Sometimes* getting the right answers too late isn't much better than
getting wrong answers.
Can you give any example of a situation where it's BETTER to get a
wrong answer early than to get the right answer late? By wrong, I
don't mean an inaccurate answer that is acceptably close to the true
value; I mean an answer which is unacceptably far away from the true
value.
Kenny McCormack wrote:
In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
On 23 Aug 2008 at 9:59, Richard Heathfield wrote:
- any performance problems are more likely to be a consequence of the
solution (i.e. your program isn't written as efficiently as it might
be) than of the translation.
You'd know /all/ about that.
In any case, correctness is far more important than speed.
False dichotomy. You seem to take the foolish approach that speed
doesn't matter at all, and choosing an O(n^2) algorithm when an O(n)
algorithm is available and in fact simpler and clearer doesn't bother
you in the least. Why? Because you've turned "portability" into an
obsession, and nothing else matters.
Yes. I think that whatever you may think of Heathfield's ideas and
posting style, even the most die-hard sycophants will have to admit that
he really put his foot in it this time.
You simply have to realize that in the real world, customers pay the
bills *and* customers don't give a darn about "how ya did it". They
care that it works and works well.
So, how does creating incorrect code quickly meet that need? Incorrect
means "it does not work".
... No real world customer is going to
prefer a "100% portable"
Who was talking about "portable"? He said "correct". If "portable" is
one of the requirements for a program (as it should be, to varying
degrees, for most programs), then it's relevant to "correctness".
However, he was making a much more general statement. Consider a
program with no portability requirements whatsoever: there is only one
machine anywhere in the entire world that it needs to run on. However,
it is required to calculate a particular value with a specified
accuracy. Richard Heathfield's point was that designing an algorithm
that actually calculates that number to the required accuracy is more
important than one which calculates a number that doesn't, no matter
how fast the algorithm is that calculates the wrong number. ja*********@verizon.net said:
Kenny McCormack wrote:
>In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
>On 23 Aug 2008 at 9:59, Richard Heathfield wrote:
- any performance problems are more likely to be a consequence of the
solution (i.e. your program isn't written as efficiently as it might
be) than of the translation.
You'd know /all/ about that.
In any case, correctness is far more important than speed.
False dichotomy. You seem to take the foolish approach that speed
doesn't matter at all, and choosing an O(n^2) algorithm when an O(n)
algorithm is available and in fact simpler and clearer doesn't bother
you in the least. Why? Because you've turned "portability" into an
obsession, and nothing else matters.
Yes. I think that whatever you may think of Heathfield's ideas and
posting style, even the most die-hard sycophants will have to admit that
he really put his foot in it this time.
You simply have to realize that in the real world, customers pay the
bills *and* customers don't give a darn about "how ya did it". They
care that it works and works well.
So, how does creating incorrect code quickly meet that need? Incorrect
means "it does not work".
Thanks for the defence, James, but you're not going to persuade trolls with
logic. Your quote (above) of their words is sufficient to show that they
haven't a clue what they're talking about. For example, the claim that I
don't care about speed is patently foolish, and it would seem likely that
the basis (such as it is) for that claim is based on a single program in
which I missed a single optimisation that would have taken longer to
implement and test than it could have conceivably saved in a million years
of running the program. The claim that I think nothing else matters other
than portability is equally silly. I happen to think, for example, that
correctness is more important than portability. If you can't get it right,
what does it matter how many platforms it can run on?
Because correctness is so important, and because programs must often be
changed, the importance of maintainability - and therefore clarity -
cannot be overstated. Clarity, correctness, modularity - these are the
cornerstones. (Okay, I know, three corners is weird.) Speed is a
nice-to-have, but it's not an essential unless it's part of correctness
(i.e. matching the requirements). Same goes for portability.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
In article <ef**********************************@b1g2000hsg.g ooglegroups.com>,
<ja*********@verizon.netwrote:
....
>So, how does creating incorrect code quickly meet that need? Incorrect
means "it does not work".
>... No real world customer is going to
prefer a "100% portable"
Who was talking about "portable"? He said "correct". If "portable" is
You're making a ridiculous point. Of course it has to be correct in
terms of producing the right answer (and whatever else is actually
required). That's just man-of-straw.
In this newsgroup, "correct" has a very different and much larger
meaning. If you stick around for awhile, you will see.
(I could write volumes more on this - to get you to see what is meant -
but I don't have that kind of time)
On 24 Aug 2008 at 13:10, ja*********@verizon.net wrote:
Kenny McCormack wrote:
>... No real world customer is going to prefer a "100% portable"
Who was talking about "portable"? He said "correct".
I believe Kenny was referencing my post, where I pointed out that
Heathfield has turned portability into such an idol that for him speed
(and even correctness) play second-fiddle to this golden calf.
On 24 Aug 2008 at 13:33, Richard Heathfield wrote:
For example, the claim that I don't care about speed is patently
foolish, and it would seem likely that the basis (such as it is) for
that claim is based on a single program in which I missed a single
optimisation that would have taken longer to implement and test than
it could have conceivably saved in a million years of running the
program.
It's based on your posting history observed over many years.
Do you deny advising someone to call time() in a busy loop for
portability, rather than using sleep(3) or whatever other mechanism is
provided on his platform?
Antoninus Twink wrote:
On 24 Aug 2008 at 13:33, Richard Heathfield wrote:
>For example, the claim that I don't care about speed is patently
foolish, and it would seem likely that the basis (such as it is) for
that claim is based on a single program in which I missed a single
optimisation that would have taken longer to implement and test than
it could have conceivably saved in a million years of running the
program.
It's based on your posting history observed over many years.
Do you deny advising someone to call time() in a busy loop for
portability, rather than using sleep(3) or whatever other mechanism is
provided on his platform?
Er, I think I did that, though I wouldn't call it "advising" anyone. It
was merely mentioned (and admitted to) as a poor implementation of
sleep. ja*********@verizon.net writes:
Keith Thompson wrote:
[...]
>You're both right. Sometimes speed is simply part of the
requirements. (And sometimes it isn't.)
*Sometimes* getting the right answers too late isn't much better than
getting wrong answers.
Can you give any example of a situation where it's BETTER to get a
wrong answer early than to get the right answer late? By wrong, I
don't mean an inaccurate answer that is acceptably close to the true
value; I mean an answer which is unacceptably far away from the true
value.
Perhaps under some bizarre circumstances. But my point was just that
in *some* circumstances, late answers are no better than wrong
answers, not that wrong answers are acceptable.
(You wrote "unacceptably far away"; it's difficult to argue that that
would be acceptable.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
>On 24 Aug 2008 at 13:10, ja*********@verizon.net wrote:
>Kenny McCormack wrote:
>>... No real world customer is going to prefer a "100% portable"
Who was talking about "portable"? He said "correct".
I believe Kenny was referencing my post, where I pointed out that
Heathfield has turned portability into such an idol that for him speed
(and even correctness) play second-fiddle to this golden calf.
Yes, and also that, in the lingo of this newsgroup, "correct" means
"100% portable". This statement is not argumentation; it is cold, hard
fact.
The problem is that, by redefining most of the standard concepts that
most of us know and use in our lives as programmers, they (the CLC regs)
have painted themselves into a corner. They can no longer use ordinary
terms like "correct" in their ordinary sense, since they have gone to
such lengths to make everything means something else (in the CLC frame
of reference).
I am reminded of how, on the old "What's My Line?" program, they redefined
the term "animal" to mean, essentially, "2 or 4 footed mammals". Which
is obviously limiting, in terms of what we know to really be animals.
Much like the CLC regs have defined "C" to be a tiny subset of what we
know to really be the "C" language.
In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
>On 24 Aug 2008 at 13:33, Richard Heathfield wrote:
>For example, the claim that I don't care about speed is patently
foolish, and it would seem likely that the basis (such as it is) for
that claim is based on a single program in which I missed a single
optimisation that would have taken longer to implement and test than
it could have conceivably saved in a million years of running the
program.
It's based on your posting history observed over many years.
Yes. As I've posted in my other response, they've redefined the terms,
so that "correct" doesn't mean what it normally means (to us normal
people).
>Do you deny advising someone to call time() in a busy loop for
portability, rather than using sleep(3) or whatever other mechanism is
provided on his platform?
They don't really explicitly "recommend" it - but they describe it in
terms designed to make the newbie think that it is somehow immoral to use
*any* "system specific" functionalities (*). And, of course, you all know
why I put "system specific" in quotes...
(*) And that it is somehow morally superior to do the stupid thing (the
busy loop) rather than taint their mortal soul with "system specific"
functionalities.
santosh said:
Antoninus Twink wrote:
>On 24 Aug 2008 at 13:33, Richard Heathfield wrote:
>>For example, the claim that I don't care about speed is patently
foolish, and it would seem likely that the basis (such as it is) for
that claim is based on a single program in which I missed a single
optimisation that would have taken longer to implement and test than
it could have conceivably saved in a million years of running the
program.
It's based on your posting history observed over many years.
Do you deny advising someone to call time() in a busy loop for
portability, rather than using sleep(3) or whatever other mechanism is
provided on his platform?
Er, I think I did that, though I wouldn't call it "advising" anyone. It
was merely mentioned (and admitted to) as a poor implementation of
sleep.
Yes, I too have said that a busy loop is the only portable way to do it,
and I too have said that it's a lousy idea. The troll understands this
really, but he has to pretend otherwise. The truth does not suit his
purposes.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999 ga*****@shell.xmission.com (Kenny McCormack) writes:
In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
>>On 23 Aug 2008 at 9:59, Richard Heathfield wrote:
>>- any performance problems are more likely to be a consequence of the
solution (i.e. your program isn't written as efficiently as it might
be) than of the translation.
You'd know /all/ about that.
>>In any case, correctness is far more important than speed.
False dichotomy. You seem to take the foolish approach that speed
doesn't matter at all, and choosing an O(n^2) algorithm when an O(n)
algorithm is available and in fact simpler and clearer doesn't bother
you in the least. Why? Because you've turned "portability" into an
obsession, and nothing else matters.
Yes. I think that whatever you may think of Heathfield's ideas and
posting style, even the most die-hard sycophants will have to admit that
he really put his foot in it this time.
You simply have to realize that in the real world, customers pay the
bills *and* customers don't give a darn about "how ya did it". They
care that it works and works well. No real world customer is going to
prefer a "100% portable" solution that is so slow that, for all
practical purposes, it can be said to simply not work. Nor is any real
world customer going to answer in anything other than the obvious way
when asked "So, Mr. Customer who is paying my bills, I can make this
code run faster - making you look better to your bosses - but at the
cost of making it not quite so aesthetically pleasing to the denizens of
this Usenet newsgroup called (amazingly enough) 'comp.lang.c'. Whaddya
think? Should I do it?"
Mind you, all of the above is spoken as one who really does take pride
in my work, likes to make my code aesthetically pleasing, and is
actually somewhat miffed to find that my customers really don't give a
darn about "how ya did it". But that's reality - a domain in which few
clc regulars have had to function in, in decades.
Extremely well said.
>
Maybe AT should re-post his little dialog between CBF and his
hypothetical customer. Was quite illuminating.
--
In article <g8**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
....
>Mind you, all of the above is spoken as one who really does take pride
in my work, likes to make my code aesthetically pleasing, and is
actually somewhat miffed to find that my customers really don't give a
darn about "how ya did it". But that's reality - a domain in which few
clc regulars have had to function in, in decades.
Extremely well said.
Elvis: Thank you very much!
In article <ea**********************************@y21g2000hsf. googlegroups.com>,
<ja*********@verizon.netwrote:
>Keith Thompson wrote:
>*Sometimes* getting the right answers too late isn't much better than
getting wrong answers.
Can you give any example of a situation where it's BETTER to get a
wrong answer early than to get the right answer late?
If you're asking the wrong question anyways, it doesn't matter what the
answer is, and the sooner you get it the sooner you can discover it's
useless.
dave
(had that happen more often than I care to admit)
--
Dave Vandervies dj3vande at eskimo dot com
loose the global variables. Really.
Please don't. I'd much prefer it if you kept them under control, or humanely
put them to sleep. --Richard Heathfield in comp.lang.c dj******@csclub.uwaterloo.ca.invalid writes:
In article <ea**********************************@y21g2000hsf. googlegroups.com>,
<ja*********@verizon.netwrote:
>>Keith Thompson wrote:
>>*Sometimes* getting the right answers too late isn't much better than
getting wrong answers.
Can you give any example of a situation where it's BETTER to get a
wrong answer early than to get the right answer late?
If you're asking the wrong question anyways, it doesn't matter what the
answer is, and the sooner you get it the sooner you can discover it's
useless.
If you're computing a course to get away from some Really Bad Thing
that's about to happen, getting an incorrect course that takes you
safely to the wrong place is better than waiting so long that the
Really Bad Thing gets you before you can leave.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson said: dj******@csclub.uwaterloo.ca.invalid writes:
>In article
<ea**********************************@y21g2000hsf .googlegroups.com>,
<ja*********@verizon.netwrote:
>>>Keith Thompson wrote:
>>>*Sometimes* getting the right answers too late isn't much better than
getting wrong answers.
Can you give any example of a situation where it's BETTER to get a
wrong answer early than to get the right answer late?
If you're asking the wrong question anyways, it doesn't matter what the
answer is, and the sooner you get it the sooner you can discover it's
useless.
If you're computing a course to get away from some Really Bad Thing
that's about to happen, getting an incorrect course that takes you
safely to the wrong place is better than waiting so long that the
Really Bad Thing gets you before you can leave.
If you adopt the reasonable position that your personal safety is the
overriding requirement and you want it RIGHT NOW, then any course that
results in your personal safety being assured *is* a correct course and
fails to be a counterexample. And if there is no such course, then the
proper thing to do is to tell the computer to keep spitting out *accurate*
solutions, sorted and displayed by increasing risk, until you choose one
of them (presumably one that's at or near the top of the list). That way,
you decide how much time it can spend on finding solutions instead of
letting it decide for itself.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Keith Thompson wrote:
) If you're computing a course to get away from some Really Bad Thing
) that's about to happen, getting an incorrect course that takes you
) safely to the wrong place is better than waiting so long that the
) Really Bad Thing gets you before you can leave.
It could be argued that 'computing a course to get away from ARBTTATH'
implies that any course that 'gets you away from ARBTTATH' is a correct
course, so 'getting an incorrect course' implies *not* getting away from it.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
Willem said:
Keith Thompson wrote:
) If you're computing a course to get away from some Really Bad Thing
) that's about to happen, getting an incorrect course that takes you
) safely to the wrong place is better than waiting so long that the
) Really Bad Thing gets you before you can leave.
It could be argued that 'computing a course to get away from ARBTTATH'
implies that any course that 'gets you away from ARBTTATH' is a correct
course, so 'getting an incorrect course' implies *not* getting away from
it.
But what if your flight from ARBTTATH drives you into the clutches of A
Really Bad Thing That Might Not Otherwise Have Happened (e.g. your
submarine is fleeing the ARBTTATH-beast by going at full speed as the
computer suggests, but then it smacks into a trench wall, killing all
hands)? Presumably "computing a course to get away from ARBTTATH" contains
the implicit assumption 'in relative safety', so not all courses that get
you away from ARBTTATH are necessarily equal in value, and the task of
differentiating between them will take time.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard Heathfield <rj*@see.sig.invalidwrites:
raashid bhatt said:
>is there any standards that tell us how c code has to be compiled into
machine code
No. C code need not even *be* compiled into a particular machine's machine
code. Often it is not - it is compiled (translated) into a particular
machine's assembly language instead. It could even be compiled into some
completely different language. Or it might not be compiled at all (C
interpreters exist).
ASM is another language. So when is translation not compilation?
Keith Thompson <ks***@mib.orgwrites:
Richard Heathfield <rj*@see.sig.invalidwrites:
>Richard Tobin said:
>>In article <lp******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
In any case, correctness is far more important than speed.
Not always. For some purposes, as someone used to have in their
signature, "late answers are wrong answers".
Wrong answers are wrong answers, too. Getting them quicker doesn't make
them righter.
You're both right. Sometimes speed is simply part of the
requirements. (And sometimes it isn't.)
Speed is always beneficial in *everything* if the speed gain is not
offset by maintenance or stability issues.
The reason desktops are 5000 times more powerful yet nothing seems to
run much quicker than the first PCs is wasteful and lazy approaches.
If you use C and do NOT consider efficiency in most cases then you are
incompetent. ja*********@verizon.net wrote:
Keith Thompson wrote:
>Richard Heathfield <rj*@see.sig.invalidwrites:
>>Richard Tobin said:
In article <lp******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
In any case, correctness is far more important than speed.
Not always. For some purposes, as someone used to have in their
signature, "late answers are wrong answers".
Wrong answers are wrong answers, too. Getting them quicker doesn't
make them righter.
You're both right. Sometimes speed is simply part of the
requirements. (And sometimes it isn't.)
*Sometimes* getting the right answers too late isn't much better than
getting wrong answers.
Can you give any example of a situation where it's BETTER to get a
wrong answer early than to get the right answer late? By wrong, I
don't mean an inaccurate answer that is acceptably close to the true
value; I mean an answer which is unacceptably far away from the true
value.
Think of DeepThought's useless answer '42' after calculating some milion
years.
Not realy a real live example, but still ... an early answer probably would
have been pretty bad for the book 8-)
Bye, Jojo
Keith Thompson wrote:
ja*********@verizon.net writes:
....
>Can you give any example of a situation where it's BETTER to get a
wrong answer early than to get the right answer late? By wrong, I
don't mean an inaccurate answer that is acceptably close to the true
value; I mean an answer which is unacceptably far away from the true
value.
Perhaps under some bizarre circumstances. But my point was just that
in *some* circumstances, late answers are no better than wrong
answers, not that wrong answers are acceptable.
(You wrote "unacceptably far away"; it's difficult to argue that that
would be acceptable.)
Well, yes - that was precisely my point.
Richard wrote:
Keith Thompson <ks***@mib.orgwrites:
>Richard Heathfield <rj*@see.sig.invalidwrites:
>>Richard Tobin said:
In article <lp******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
In any case, correctness is far more important than speed.
Not always. For some purposes, as someone used to have in their
signature, "late answers are wrong answers".
Wrong answers are wrong answers, too. Getting them quicker doesn't make
them righter.
You're both right. Sometimes speed is simply part of the
requirements. (And sometimes it isn't.)
Speed is always beneficial in *everything* ...
Speed is not always beneficial - in real-time programming, there's often
an optimum time to do something, and extra speed beyond what's needed to
meet that deadline provides no extra benefit. The extra speed is
generally not harmful, if handled correctly by inserting an appropriate
waiting period somewhere in the process, but it isn't beneficial.
... if the speed gain is not
offset by maintenance or stability issues.
Or, getting back to the topic at hand, correctness issues?
The reason desktops are 5000 times more powerful yet nothing seems to
run much quicker than the first PCs is wasteful and lazy approaches.
If you use C and do NOT consider efficiency in most cases then you are
incompetent.
No one has suggested that efficiency be ignored, only that it's a lower
priority than correctness.
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>Re-read the original question that started this thread. Do you really
think the OP was asking about ABIs?
I took the OP to mean something like "if I'm writing a C compiler, are
there any standards I need to follow when deciding what code to
generate". And since a compiler writer usually wants his compiler to
produce code that interoperates with existing libraries and operating
system features such as signals, the answer is yes.
There are various other things he could have meant, but I chose the
interpretation that had the most interesting answer.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Richard Heathfield <rj*@see.sig.invalidwrites:
Keith Thompson said:
>dj******@csclub.uwaterloo.ca.invalid writes:
>>In article
<ea**********************************@y21g2000hs f.googlegroups.com>,
<ja*********@verizon.netwrote:
Keith Thompson wrote:
*Sometimes* getting the right answers too late isn't much better than
getting wrong answers.
Can you give any example of a situation where it's BETTER to get a
wrong answer early than to get the right answer late?
If you're asking the wrong question anyways, it doesn't matter what the
answer is, and the sooner you get it the sooner you can discover it's
useless.
If you're computing a course to get away from some Really Bad Thing
that's about to happen, getting an incorrect course that takes you
safely to the wrong place is better than waiting so long that the
Really Bad Thing gets you before you can leave.
If you adopt the reasonable position that your personal safety is the
overriding requirement and you want it RIGHT NOW, then any course that
results in your personal safety being assured *is* a correct course and
fails to be a counterexample. And if there is no such course, then the
proper thing to do is to tell the computer to keep spitting out *accurate*
solutions, sorted and displayed by increasing risk, until you choose one
of them (presumably one that's at or near the top of the list). That way,
you decide how much time it can spend on finding solutions instead of
letting it decide for itself.
The software was designed for ordinary navigation, not for emergency
situations (though it *should* work in emergencies as well). It
produces an incorrect course randomly one time out of ten. You tell
it you want to go to Argelius, and it gives you a course to Janus VI,
clearly a bug. To recover, you have to reboot the system, which takes
at least seven minutes, something you can usually live with, but not
today, blast it, so you're darned lucky it didn't plot a course into
the middle of the nearest star. The bug has been reported but not yet
fixed. And Scotty and Spock have both been on shore leave for a week
(not their idea), so there's no time to re-write the software, and the
manual override is malfunctioning and giving off multicolored sparks.
The result is "correct" for the current situation, but incorrect for
the situation for which the software was designed.
So yes, Janus VI will do nicely, thank you.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
James Kuyper <ja*********@verizon.netwrites:
Richard wrote:
>Keith Thompson <ks***@mib.orgwrites:
>>Richard Heathfield <rj*@see.sig.invalidwrites:
Richard Tobin said:
In article <lp******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>
>In any case, correctness is far more important than speed.
Not always. For some purposes, as someone used to have in their
signature, "late answers are wrong answers".
Wrong answers are wrong answers, too. Getting them quicker doesn't
make them righter.
You're both right. Sometimes speed is simply part of the
requirements. (And sometimes it isn't.)
Speed is always beneficial in *everything* ...
Speed is not always beneficial - in real-time programming, there's
often an optimum time to do something, and extra speed beyond what's
Assuming proper "wait" facilities are available this is not true. It
running efficiently even leads to power saving and reduced heat.
needed to meet that deadline provides no extra benefit. The extra
Not the point. The point is to consider. If we talk about portability we
can also consider that there is NO POINT wasting clock cycles since it
might be used in a more constricted environment later.
speed is generally not harmful, if handled correctly by inserting an
appropriate waiting period somewhere in the process, but it isn't
beneficial.
>... if the speed gain is not
offset by maintenance or stability issues.
Or, getting back to the topic at hand, correctness issues?
Sigh. Did I need to state the obvious? That I assume the faster program
also is correct?
>
>The reason desktops are 5000 times more powerful yet nothing seems to
run much quicker than the first PCs is wasteful and lazy approaches.
If you use C and do NOT consider efficiency in most cases then you are
incompetent.
No one has suggested that efficiency be ignored, only that it's a
lower priority than correctness.
I find it astonishing that you even think for ONE second that I mean a
fast WRONG program is better than a slow CORRECT one. Clearly this is
NOT what I mean.
In article <g8**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
....
>I find it astonishing that you even think for ONE second that I mean a
fast WRONG program is better than a slow CORRECT one. Clearly this is
NOT what I mean.
It's an obvious man-of-straw, but that's all they can do.
Sucks to be so mentally limited, but there you have it. ja*********@verizon.net writes:
Richard wrote:
>James Kuyper <ja*********@verizon.netwrites:
Richard wrote:
Keith Thompson <ks***@mib.orgwrites:
Richard Heathfield <rj*@see.sig.invalidwrites:
Richard Tobin said:
In article <lp******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>
>In any case, correctness is far more important than speed.
Not always. For some purposes, as someone used to have in their
signature, "late answers are wrong answers".
Wrong answers are wrong answers, too. Getting them quicker doesn't
make them righter.
You're both right. Sometimes speed is simply part of the
requirements. (And sometimes it isn't.)
Speed is always beneficial in *everything* ...
Speed is not always beneficial - in real-time programming, there's
often an optimum time to do something, and extra speed beyond what's
Assuming proper "wait" facilities are available this is not true. It
running efficiently even leads to power saving and reduced heat.
I'm sure that some systems have proper "wait" facilities. However,
your assertion "Speed is always beneficial" requires that power-saving
wait states exist in ALL such contexts, not just "some" of them, not
even "most" of them.
Speed is many things in an programmers conversation. It can be
interpreted as economy of movement too if you want to be really open
minded. e.g uses less memory. Other tasks therefore get more available
or more timeslots etc etc. To think about optimization of kinds at an
early enough stage in designing a C system is not a death knoll as many
here would have you believe. The fact that C is chosen is usually for
efficiency and speed.
Considering "speed" is imperative in many designs. Not to do so is, as I
said before, incompetent in many, many cases. Not all I grant you. But
to *CONSIDER* it in all cases can never be wrong. You might decide for
reasons highlighted in my previous post not to follow it up but to
consider it is a must.
Richard Heathfield wrote:
[...]
Clarity, correctness, modularity - these are the cornerstones.
That is funny because non of these are the strong points of C (on the
other hand availability, expressiveness and efficiency are).
August
August Karlstrom said:
Richard Heathfield wrote:
[...]
>Clarity, correctness, modularity - these are the cornerstones.
That is funny because non of these are the strong points of C (on the
other hand availability, expressiveness and efficiency are).
Perhaps it would be truer to say that none of these are the strong points
of C *programmers*. :-)
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard Heathfield <r...@see.sig.invalidwrote:
August Karlstrom said:
Richard Heathfield wrote:
Clarity, correctness, modularity - these are the
cornerstones.
That is funny because non of these are the strong
points of C (on the other hand availability,
expressiveness and efficiency are).
Perhaps it would be truer to say that none of these
are the strong points of C *programmers*. :-)
It's a poor language that blames the tools who use it. ;)
--
Peter
Richard Heathfield wrote:
August Karlstrom said:
>Richard Heathfield wrote:
[...]
>>Clarity, correctness, modularity - these are the cornerstones.
That is funny because non of these are the strong points of C (on the
other hand availability, expressiveness and efficiency are).
Perhaps it would be truer to say that none of these are the strong points
of C *programmers*. :-)
That is true to some extent. For instance, achieving modularity in C
requires quite a lot of discipline and knowledge of best practice. In
Oberon, to mention another system programming language, the module is a
language construct used in every program.
August
On 24 Aug, 09:45, "Lassie" <z...@woaini.comwrote:
"Keith Thompson" <ks...@mib.orgschreef in berichtnews:ln************@nuthaus.mib.org...
Re-read the original question that started this thread. *Do you really
think the OP was asking about ABIs?
The OP is not experienced in C,
ok
I believe he didnt know himself what he was
asking.
I think he was perfectly clear in his own mind about what he was
asking. He was asking for the code generation strategy for C. I'm sure
compiler writers have such a strategy for each architecture they
support.
But (we know) it isn't standardised.
But as far as his question concerns, ABI answers it pretty much yes.
no. ABIs only seem to cover call and return conventions (maybe program
startup as well). General code isn't covered at all.
It's not a 100% C to machine instruction standard no,
nor even 20%
but they cover a lot
of binary interfacing yes.
*interfacing*- thats not what most code does
--
Nick Keighley This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: konf |
last post by:
Hallo,
I tried to compile PGSQL 7.4 and I got error (durring make):
ar: command not found
What is it? Whe I can found it?
I have:
$ uname -a
SunOS ... 5.8 Generic_108528-03 sun4u sparc...
|
by: Sune |
last post by:
Hi,
previously I used Eclipse CDT for compiling my files just to get
started with C and leave C++ behind. Now it's time to get a little more
serious so I've moved my files to a new workplace and...
|
by: FireStarter |
last post by:
Guys, in the code that follows, why does the method F() still compile, even if
DBG is undefined? Inside method G(), the code inside <#if DBG> does not compile
(notice that I can write whatever I...
|
by: Dan |
last post by:
Hi,
I have a problem using an aspx page with a Control on it. I get the
following error message
Compiler Error Message: CS1595: 'Test.Class2' is defined in multiple
places; using definition...
|
by: ktrvnbq02 |
last post by:
Hi,
We have an ASP.NET application built in Release mode via Visual Studio.
All of the C# code is in the code-behind files (i.e. *.aspx.cs files)
and there is no C# in the *.aspx files...
|
by: thomson |
last post by:
Hi all,
I have compiled by .net web applicaion in my local machine ,
and a dll has been created on the bin Directory,
And i have copied the entire application using xcopy deployment to a...
|
by: Robert |
last post by:
I have a number of web projects converted from 1.1 to 2.0 in VS2005.
I am methodically seeing the error below:
The element 'compilation' has invalid child element 'compilers'. List of...
|
by: alban |
last post by:
Hello
I have got some problems of compilation on a AIX IBM,
I use the XLC compilator (And I can't install another one).
I try to compile code Pro*c ".pc" (oracle), I need do a pre-compilation...
|
by: Bob |
last post by:
Hi,
In VS2003 conditional compilation constants and their state could be defined
at project level.
I was using this to control what features where offered by various builds.
i.e....
|
by: mwelsh1118 |
last post by:
Why doesn't C# allow incremental compilation like Java?
Specifically, in Java I can compile single .java files in isolation.
The resulting individual .class files can be grouped into .jar files....
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |
