* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-29 23:26 ` Bakul Shah
@ 2012-10-29 23:31 ` Bakul Shah
2012-10-29 23:36 ` erik quanstrom
` (3 subsequent siblings)
4 siblings, 0 replies; 31+ messages in thread
From: Bakul Shah @ 2012-10-29 23:31 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Mon, 29 Oct 2012 16:26:52 PDT Bakul Shah <bakul@bitblocks.com> wrote:
>
> /sys/src/cmd follows plan9 c, not c99, right? But pick a
> similar set of programs. If this happens, I claim it would be
> because programs assume something not guaranteed by the
> compiler.
Oops. Meant to say "not guaranteed by the standard".
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-29 23:26 ` Bakul Shah
2012-10-29 23:31 ` Bakul Shah
@ 2012-10-29 23:36 ` erik quanstrom
2012-10-29 23:58 ` Charles Forsyth
2012-10-30 0:35 ` Bakul Shah
2012-10-30 1:21 ` Kurt H Maier
` (2 subsequent siblings)
4 siblings, 2 replies; 31+ messages in thread
From: erik quanstrom @ 2012-10-29 23:36 UTC (permalink / raw)
To: 9fans
> No disagreement there on "requiring" optimization. But my
> point was that a programmer should understand the standard
> rather than complain when he gets "surprised" due to his lack
> of knowledge.
i agree that one should know the language. but i'm not sure i'll
say it's the programmer's fault when the compiler does things to
the programmer. that to me goes a bit too far.
> /sys/src/cmd follows plan9 c, not c99, right? But pick a
> similar set of programs. If this happens, I claim it would be
> because programs assume something not guaranteed by the
> compiler.
and i can design a standards-compatable compiler that will break
most any c program.
this is similar to saying that i can design a namespace that will
break almost any plan 9 program.
what i think has broken down is common sense among compiler
writers. they're too focused on being fast, and not focused enough
on being *useful*.
> > > > it goes without saying, i think a compiler that largely does what you
> > > > ask it to optimizes the scarce resource: developer time.
> > >
> > > That is a separate issue.
> >
> > actually, i think it *is* the issue.
>
> Best way to save developer time is to program in a HLL and not
> worry about bit fiddling. C is not a HLL.
this is a spurious argument, since we are in fact talking about c.
- erik
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-29 23:36 ` erik quanstrom
@ 2012-10-29 23:58 ` Charles Forsyth
2012-10-30 0:52 ` Bakul Shah
2012-10-30 7:55 ` tlaronde
2012-10-30 0:35 ` Bakul Shah
1 sibling, 2 replies; 31+ messages in thread
From: Charles Forsyth @ 2012-10-29 23:58 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
[-- Attachment #1: Type: text/plain, Size: 633 bytes --]
"But my point was that a programmer should understand the standard"
But suppose the standard does not evidently aim to be understood, in the
generally understood meaning of "understood",
or there are more words in the standard than will ever appear in the
programmer's own programs?
Worse! "Standard" doesn't imply a fixed point ("oh, that syntax/semantics
is so last year!").
I think looking into memset and deciding it's not worthwhile calling is
perhaps overly enthusiastic.
Actually, it's wrong, because it overlooks the side-effect, and an
optimiser for a language with side-effects
should take that into account.
[-- Attachment #2: Type: text/html, Size: 965 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-29 23:58 ` Charles Forsyth
@ 2012-10-30 0:52 ` Bakul Shah
2012-10-30 1:01 ` erik quanstrom
2012-10-30 7:55 ` tlaronde
1 sibling, 1 reply; 31+ messages in thread
From: Bakul Shah @ 2012-10-30 0:52 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Mon, 29 Oct 2012 23:58:23 -0000 Charles Forsyth <charles.forsyth@gmail.com> wrote:
>
> "But my point was that a programmer should understand the standard"
>
> But suppose the standard does not evidently aim to be understood, in the
> generally understood meaning of "understood",
> or there are more words in the standard than will ever appear in the
> programmer's own programs?
The C standard is not too hard to understand. For something
worse try one of those ITU standards! Try IEEE 802 standards!
I have had to read the Bridging standard many many more times
(compared to the C standard) to make sense of it. The
standards *shouldn't* be so horrible but they are. And one
does what is needed to get the job done.
> Worse! "Standard" doesn't imply a fixed point ("oh, that syntax/semantics
> is so last year!").
> I think looking into memset and deciding it's not worthwhile calling is
> perhaps overly enthusiastic.
I ask again. Who decides where the line is drawn? I think that
in a competitive environment the only thing that can restrain
people is the standard. Unfortunately.
> Actually, it's wrong, because it overlooks the side-effect, and an
> optimiser for a language with side-effects
> should take that into account.
They put in "volatile" to ensure side-effects happen. Hasn't
worked too well.
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-30 0:52 ` Bakul Shah
@ 2012-10-30 1:01 ` erik quanstrom
0 siblings, 0 replies; 31+ messages in thread
From: erik quanstrom @ 2012-10-30 1:01 UTC (permalink / raw)
To: 9fans
> The C standard is not too hard to understand. For something
> worse try one of those ITU standards! Try IEEE 802 standards!
> I have had to read the Bridging standard many many more times
> (compared to the C standard) to make sense of it. The
> standards *shouldn't* be so horrible but they are. And one
> does what is needed to get the job done.
this is logical fallacy.
the fact that there are larger and more obtuse standards,
does not mean that the c standard is readable or understandable,
by their normal definitions.
> > Actually, it's wrong, because it overlooks the side-effect, and an
> > optimiser for a language with side-effects
> > should take that into account.
>
> They put in "volatile" to ensure side-effects happen. Hasn't
> worked too well.
that's incorrect. it was a hack to try to sneak a memory
model in the side door. side effects are something else entirely.
- erik
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-29 23:58 ` Charles Forsyth
2012-10-30 0:52 ` Bakul Shah
@ 2012-10-30 7:55 ` tlaronde
1 sibling, 0 replies; 31+ messages in thread
From: tlaronde @ 2012-10-30 7:55 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Mon, Oct 29, 2012 at 11:58:23PM +0000, Charles Forsyth wrote:
>
> But suppose the standard does not evidently aim to be understood, in the
> generally understood meaning of "understood",
> or there are more words in the standard than will ever appear in the
> programmer's own programs?
Do you mean as if standards were designed or "improved" by committees?
Please: stop spreading FUD! (Were are my drops? I have tachycardia
again!)
--
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-29 23:36 ` erik quanstrom
2012-10-29 23:58 ` Charles Forsyth
@ 2012-10-30 0:35 ` Bakul Shah
2012-10-30 1:10 ` erik quanstrom
2012-10-30 1:46 ` cinap_lenrek
1 sibling, 2 replies; 31+ messages in thread
From: Bakul Shah @ 2012-10-30 0:35 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Mon, 29 Oct 2012 19:36:16 EDT erik quanstrom <quanstro@quanstro.net> wrote:
> > No disagreement there on "requiring" optimization. But my
> > point was that a programmer should understand the standard
> > rather than complain when he gets "surprised" due to his lack
> > of knowledge.
>
> i agree that one should know the language. but i'm not sure i'll
> say it's the programmer's fault when the compiler does things to
> the programmer. that to me goes a bit too far.
Not a question of fault but IMHO a programmer, like a
carpenter or anyone who does real work, has to experiment and
learn the strengths and weaknesses of his tools of his trade
if he wants to become competent.
The language standard can only mandate what you can do within
the language. For instace, if the blog writer had done this:
...
memcpy(a, 0, sizeof a);
for (i = 0; i < sizeof a; i++)
assert(a[i] == 0);
return 0;
}
He would have seen that every a[i] was indeed 0. But if you
use means external to the language (such as used a debugger or
look at the assembly language) to check side-effects, you get
to see the underside of optimization. Ugly, confusing and
possibly surprising. If you want to do something not covered
in the standard, learn what the compiler does and find a
compiler dependent way.
> > /sys/src/cmd follows plan9 c, not c99, right? But pick a
> > similar set of programs. If this happens, I claim it would be
> > because programs assume something not guaranteed by the
> > compiler.
>
> and i can design a standards-compatable compiler that will break
> most any c program.
Care to give an example? I am genuinely interested. The C
standard is far from perfect but it has worked well enough.
[Where is doug gywn when we need him?]
> what i think has broken down is common sense among compiler
> writers. they're too focused on being fast, and not focused enough
> on being *useful*.
I agree but I am afraid they do that because that is what the
market demands. Pretty much most of the software that the
Internet runs on + used by most people + businesses uses C or
C++ so C/C++ and their standards have been *useful* (but see
below). Fast does matter when you scale up (a big company may
need 18K servers instead of 20K and that results in savings
and less heat generation).
If you want to whine, whine about the fact that *we* (all of
us) have lost common sense in pretty much every field. Food,
medicine, media, politics, religion, consumption, you name it.
> > > > > it goes without saying, i think a compiler that largely does what you
> > > > > ask it to optimizes the scarce resource: developer time.
> > > >
> > > > That is a separate issue.
> > >
> > > actually, i think it *is* the issue.
> >
> > Best way to save developer time is to program in a HLL and not
> > worry about bit fiddling. C is not a HLL.
>
> this is a spurious argument, since we are in fact talking about c.
Sorry but IMHO "saving developer time" & C don't mix well. I
am just pointing out what modern C is and how to survive, not
what it should be. I gave up on that a long time ago!
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-30 0:35 ` Bakul Shah
@ 2012-10-30 1:10 ` erik quanstrom
2012-10-30 3:06 ` Bakul Shah
2012-10-30 1:46 ` cinap_lenrek
1 sibling, 1 reply; 31+ messages in thread
From: erik quanstrom @ 2012-10-30 1:10 UTC (permalink / raw)
To: 9fans
On Mon Oct 29 20:36:26 EDT 2012, bakul@bitblocks.com wrote:
> Not a question of fault but IMHO a programmer, like a
> carpenter or anyone who does real work, has to experiment and
> learn the strengths and weaknesses of his tools of his trade
> if he wants to become competent.
>
> The language standard can only mandate what you can do within
> the language. For instace, if the blog writer had done this:
>
> ...
> memcpy(a, 0, sizeof a);
> for (i = 0; i < sizeof a; i++)
> assert(a[i] == 0);
> return 0;
> }
>
> He would have seen that every a[i] was indeed 0. But if you
> use means external to the language (such as used a debugger or
> look at the assembly language) to check side-effects, you get
> to see the underside of optimization. Ugly, confusing and
> possibly surprising. If you want to do something not covered
> in the standard, learn what the compiler does and find a
> compiler dependent way.
you are arguing for a cartoon hammer that runs away when you're
not looking at it.
> > and i can design a standards-compatable compiler that will break
> > most any c program.
>
> Care to give an example? I am genuinely interested. The C
> standard is far from perfect but it has worked well enough.
> [Where is doug gywn when we need him?]
oh, there are a number of obvious under-handed tricks. let's see,
for an intel compiler, change the structure padding to something bizarre
like 3 bytes. that will break a large number of linux drivers. (the 57711
for sure!) rearrange structure elements other than the first.
you can change from signed-preserving to unsigned preserving.
that'll catch a lot of folks out. do ones-complement arithmetic
(i believe that's still legal). have 10-bit bytes. 20 bit shorts, 40 bit
ints, 45-bit longs and 80-bit vlongs. (i'm not sure that's completely
legal, but you get the point.) make pointers to different types different
sizes. the list goes on. the combinations are silly, too. default
unsigned characters with unsigned preserving behavior. good luck
debugging that!
and since you would allow compilers to mess with side effects, we could
have a genuine field day.
> > what i think has broken down is common sense among compiler
> > writers. they're too focused on being fast, and not focused enough
> > on being *useful*.
>
> I agree but I am afraid they do that because that is what the
> market demands. Pretty much most of the software that the
> Internet runs on + used by most people + businesses uses C or
> C++ so C/C++ and their standards have been *useful* (but see
> below). Fast does matter when you scale up (a big company may
> need 18K servers instead of 20K and that results in savings
> and less heat generation).
i don't understand your use of the world "useful". to me, the c
standard has become like a political issue. it's something to
game for personal advantage.
- erik
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-30 1:10 ` erik quanstrom
@ 2012-10-30 3:06 ` Bakul Shah
2012-10-30 3:16 ` Corey Thomasson
0 siblings, 1 reply; 31+ messages in thread
From: Bakul Shah @ 2012-10-30 3:06 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Mon, 29 Oct 2012 21:10:41 EDT erik quanstrom <quanstro@quanstro.net> wrote:
>
> you are arguing for a cartoon hammer that runs away when you're
> not looking at it.
That is an excellent definition of optimization! Typical
optimizations:
- putting a variable in a register
- caching a value in a register
- moving a computation outside a loop
- inlining
- not doing something that is not going to be used
- reusing a register (so the old variable no longer exists)
- moving a computation to callsite from the called function
(partial inlining)
- partial evaluation
- caching a result
- don't allocate a variable if not used
In all these cases, the generated code will look different
compared to when *no* optimization is done.
The issue again is, who draws the line? And where? And is it
the same for every processor model? [An optimization on one
can be a pessimization on another]. Note that even the
simple flat memory model of C is an illusion.
The "stalin" Scheme to C compiler can do whole program
optimization and produces amazingly efficient programs --
often better than hand written C code. Letting it do the
optimization saves a lot of developer time, and more
importantly, one can write clear understandable code and not
have to hand optimize it into spaghetti code (where some
obscure bug can hide). Now the compiler is slow so I would
only use it if I am going to run something for a very long
time.
I would argue that one should not put limits on what can be
optimized but should keep the language simple and clearly pin
down semantics as precisely as possible.
> > > and i can design a standards-compatable compiler that will break
> > > most any c program.
> >
> > Care to give an example? I am genuinely interested. The C
> > standard is far from perfect but it has worked well enough.
> > [Where is doug gywn when we need him?]
>
> oh, there are a number of obvious under-handed tricks. let's see,
> for an intel compiler, change the structure padding to something bizarre
> like 3 bytes. that will break a large number of linux drivers. (the 57711
> for sure!) rearrange structure elements other than the first.
> you can change from signed-preserving to unsigned preserving.
> that'll catch a lot of folks out. do ones-complement arithmetic
> (i believe that's still legal). have 10-bit bytes. 20 bit shorts, 40 bit
> ints, 45-bit longs and 80-bit vlongs. (i'm not sure that's completely
> legal, but you get the point.) make pointers to different types different
> sizes. the list goes on. the combinations are silly, too. default
> unsigned characters with unsigned preserving behavior. good luck
> debugging that!
My head hurts! Clearly programs that break won't be standard
compliant :-)
> > > what i think has broken down is common sense among compiler
> > > writers. they're too focused on being fast, and not focused enough
> > > on being *useful*.
> >
> > I agree but I am afraid they do that because that is what the
> > market demands. Pretty much most of the software that the
> > Internet runs on + used by most people + businesses uses C or
> > C++ so C/C++ and their standards have been *useful* (but see
> > below). Fast does matter when you scale up (a big company may
> > need 18K servers instead of 20K and that results in savings
> > and less heat generation).
>
> i don't understand your use of the world "useful". to me, the c
> standard has become like a political issue. it's something to
> game for personal advantage.
gcc etc. are used to deliver a lot of code that is used in
real word. And without a standard there would've been lot
less interoperability and far more bugs.
You seem to be arguing for K&R as the standard or something
but we already tried that until 1989. A standard was needed
due to the success of C and with indepenedent implementations
that interpreted unwritten things in a different way from K&R.
I doubt Ritchie and co wanted to take an active and central
role (and I am not familiar with the history) but my guess
is only that could've kept the standard simple and readable.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-30 3:06 ` Bakul Shah
@ 2012-10-30 3:16 ` Corey Thomasson
2012-10-30 13:08 ` erik quanstrom
0 siblings, 1 reply; 31+ messages in thread
From: Corey Thomasson @ 2012-10-30 3:16 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
[-- Attachment #1: Type: text/plain, Size: 879 bytes --]
On 29 October 2012 23:06, Bakul Shah <bakul@bitblocks.com> wrote:
>
> gcc etc. are used to deliver a lot of code that is used in
> real word. And without a standard there would've been lot
> less interoperability and far more bugs.
Most interoperability delivered by gcc comes from the fact that gcc is
widespread, not that the standard is effective. If it was we wouldn't need
to port gcc to everything.
>
You seem to be arguing for K&R as the standard or something
> but we already tried that until 1989. A standard was needed
> due to the success of C and with indepenedent implementations
> that interpreted unwritten things in a different way from K&R.
> I doubt Ritchie and co wanted to take an active and central
> role (and I am not familiar with the history) but my guess
> is only that could've kept the standard simple and readable.
>
>
[-- Attachment #2: Type: text/html, Size: 1436 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-30 3:16 ` Corey Thomasson
@ 2012-10-30 13:08 ` erik quanstrom
2012-10-30 15:15 ` arnold
0 siblings, 1 reply; 31+ messages in thread
From: erik quanstrom @ 2012-10-30 13:08 UTC (permalink / raw)
To: 9fans
On Mon Oct 29 23:17:25 EDT 2012, cthom.lists@gmail.com wrote:
> On 29 October 2012 23:06, Bakul Shah <bakul@bitblocks.com> wrote:
>
> >
> > gcc etc. are used to deliver a lot of code that is used in
> > real word. And without a standard there would've been lot
> > less interoperability and far more bugs.
>
>
> Most interoperability delivered by gcc comes from the fact that gcc is
> widespread, not that the standard is effective. If it was we wouldn't need
> to port gcc to everything.
even clang got forced into bug-for-bug compatability mode.
- erik
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-30 13:08 ` erik quanstrom
@ 2012-10-30 15:15 ` arnold
0 siblings, 0 replies; 31+ messages in thread
From: arnold @ 2012-10-30 15:15 UTC (permalink / raw)
To: 9fans
> > > gcc etc. are used to deliver a lot of code that is used in
> > > real word. And without a standard there would've been lot
> > > less interoperability and far more bugs.
This remains true. It is possible and not that difficult to write
code that can be successfully and correctly compiled by multiple compilers
(like, oh, i dunno, maybe, GNU awk :-).
> > Most interoperability delivered by gcc comes from the fact that gcc is
> > widespread, not that the standard is effective. If it was we wouldn't need
> > to port gcc to everything.
>
> even clang got forced into bug-for-bug compatability mode.
Also the Intel compiler, ICC.
Like many things, standards seem to obey a bell curve. The problem is that
we're on the descending side on so many of them... (Dare I say it? "POSIX".
Freel free to run screaming in horror. :-)
Having lived through the Unix wars of the late 80s and early 90s, I think
that overall standards are a good thing. It just seems that more recently
the comittees keep adding stuff in order to justify their continued existence,
instead of solving real problems.
Arnold
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-30 0:35 ` Bakul Shah
2012-10-30 1:10 ` erik quanstrom
@ 2012-10-30 1:46 ` cinap_lenrek
1 sibling, 0 replies; 31+ messages in thread
From: cinap_lenrek @ 2012-10-30 1:46 UTC (permalink / raw)
To: 9fans
m(
--
cinap
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-29 23:26 ` Bakul Shah
2012-10-29 23:31 ` Bakul Shah
2012-10-29 23:36 ` erik quanstrom
@ 2012-10-30 1:21 ` Kurt H Maier
2012-10-30 8:07 ` tlaronde
2012-10-30 10:26 ` Richard Miller
4 siblings, 0 replies; 31+ messages in thread
From: Kurt H Maier @ 2012-10-30 1:21 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Mon, Oct 29, 2012 at 04:26:52PM -0700, Bakul Shah wrote:
>
> Best way to save developer time is to program in a HLL and not
> worry about bit fiddling. C is not a HLL.
>
Two problems with this:
1) Developer time is not worth saving, because developers are cheap and
they don't use their time very well in the first place.
2) C was a high-level language during the era where developer time was
worth saving.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-29 23:26 ` Bakul Shah
` (2 preceding siblings ...)
2012-10-30 1:21 ` Kurt H Maier
@ 2012-10-30 8:07 ` tlaronde
2012-10-30 10:26 ` Richard Miller
4 siblings, 0 replies; 31+ messages in thread
From: tlaronde @ 2012-10-30 8:07 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Mon, Oct 29, 2012 at 04:26:52PM -0700, Bakul Shah wrote:
>
> Best way to save developer time is to program in a HLL and not
> worry about bit fiddling. C is not a HLL.
The HLL will have to have a compiler. If the compiler is, finally,
machine instructions, how does one guarantee that it does exactly what
intended on different architectures. If the next level language, near
machine but high level is used---it's C---you are relying on what you
wanted to escape from...
The only mean to be sure is to have a HLL that allows only HL
instructions, like macroscopic, due to its complexity, escapes from the
uncertainty of quantics effects. This is to say, the language will not
allow you to do everything.
The practical solution is to have a language that is near the machine,
sufficiently abstracted from the machines that assembly is scarcely
needed, with some small set of primitives, a small manual, a clear
(once again: small) set of what is guaranteed and caveats about
what is not, and let the programmer decide without the compiler
"guessing" or improving---and a way of writting sources so that a
programmer can optimize his code on this level (this is litterate
programming). C was very near a perfect practical
solution; C89 was not bad; C99 has improved some things but added
too many things on the border (where there is already uncertainty
about what has to be done because "it depends").
--
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-29 23:26 ` Bakul Shah
` (3 preceding siblings ...)
2012-10-30 8:07 ` tlaronde
@ 2012-10-30 10:26 ` Richard Miller
2012-10-30 10:39 ` dexen deVries
4 siblings, 1 reply; 31+ messages in thread
From: Richard Miller @ 2012-10-30 10:26 UTC (permalink / raw)
To: 9fans
> Best way to save developer time is to program in a HLL and not
> worry about bit fiddling. C is not a HLL.
C was created as a language to do bit fiddling in - a tool for writing
assembly language a bit more productively than doing it by hand. The
original Unix C compiler was a tool for writing PDP11 assembly
language. Later when the prospect of Unix on other architectures
began to emerge, the 7th edition Unix "portable C compiler" was a
family of tools for writing assembly language on different machines.
C was designed by and used by systems programmers who were intimately
familiar with their machine's instruction set, and the code generation
was so simple and straightforward that to such programmers it would be
obvious what instructions would correspond to a given bit of C. The
low-level directness of C made it easy to write efficient code, so
there was no need for the compiler itself to try to do clever
"optimisations".
Such a language was and still is just what is needed for writing
device drivers and the lowest layers of OS kernels where things like
memory layout and instruction ordering are important. It's not such a
good match for writing the more abstract upper layers of an OS, and
even less so for applications programming. I think it's unfortunate
that C ended up being so widely (mis)used for applications
programming, and by applications programmers who have never learned
assembly language, causing pressure for compilers to be obfuscated
with semantics-perverting "optimisations" and, in an attempt to
compensate for this, the language to be defaced with "features" like
volatile and __attribute__ and whatnot.
I think inferno got it about right: write the kernel in C, and
the applications in a high level language (limbo).
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
2012-10-30 10:26 ` Richard Miller
@ 2012-10-30 10:39 ` dexen deVries
0 siblings, 0 replies; 31+ messages in thread
From: dexen deVries @ 2012-10-30 10:39 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Tuesday 30 of October 2012 10:26:52 Richard Miller wrote:
> > Best way to save developer time is to program in a HLL and not
> > worry about bit fiddling. C is not a HLL.
>
> C was created as a language to do bit fiddling in - a tool for writing
> assembly language a bit more productively than doing it by hand. (..)
slightly branching off:
true that. however, people still manage medium-to-high level with a bit of
macros and advanced stuff.
the other day i browsed http://9hal.ath.cx/usr/cinap_lenrek/cifsd.tgz -- looks
high-level enough for me.
putty uses home-brew coroutines in portable C, as per
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
--
dexen deVries
[[[↓][→]]]
How often I found where I should be going
only by setting out for somewhere else.
-- R. Buckminster Fuller
^ permalink raw reply [flat|nested] 31+ messages in thread