Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #14135 > unrolled thread

The way to read STL source code

Back to article view | Back to comp.lang.c++

Contents

  The way to read STL source code Stanley Rice <heconghui@gmail.com> - 2012-02-16 23:18 -0800
    Re: The way to read STL source code Juha Nieminen <nospam@thanks.invalid> - 2012-02-17 07:29 +0000
      Re: The way to read STL source code Stanley Rice <heconghui@gmail.com> - 2012-02-17 00:56 -0800
        Re: The way to read STL source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-17 01:11 -0800
        Re: The way to read STL source code Juha Nieminen <nospam@thanks.invalid> - 2012-02-17 12:31 +0000
          Re: The way to read STL source code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-17 16:35 +0000
            Re: The way to read STL source code Juha Nieminen <nospam@thanks.invalid> - 2012-02-17 20:38 +0000
              Re: The way to read STL source code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-21 21:17 +0000
          Re: The way to read STL source code Stanley Rice <heconghui@gmail.com> - 2012-02-17 16:55 -0800
            Re: The way to read STL source code Ian Collins <ian-news@hotmail.com> - 2012-02-18 14:13 +1300
            Re: Learning to code by reading code (was: The way to read STL source code) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-18 19:00 -0500
              Re: Learning to code by reading code "MikeWhy" <boat042-nospam@yahoo.com> - 2012-02-18 22:34 -0600
              Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-19 03:54 -0500
                Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-19 10:42 +0100
                Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-20 03:39 -0500
              Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-19 03:54 -0500
                Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-19 08:40 -0800
                  Re: Learning to code by reading code "MikeWhy" <boat042-nospam@yahoo.com> - 2012-02-19 13:17 -0600
                    Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 02:32 -0800
                      Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-20 13:02 +0100
                        Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 05:09 -0800
                          Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-20 15:11 +0100
                            Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 07:39 -0800
                  Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-20 04:14 -0500
                    Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-20 11:14 +0100
                    Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 02:49 -0800
                      Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-20 13:02 +0100
                        Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 05:18 -0800
                          Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-20 13:53 +0000
                            Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 01:32 -0800
                              Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-21 16:16 +0100
                                Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 08:40 -0800
                      Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-20 17:36 -0500
                        Re: Learning to code by reading code Mike McCarty <mcmccarty@gmail.com> - 2012-02-20 15:27 -0800
                        Re: Learning to code by reading code Dombo <dombo@disposable.invalid> - 2012-02-21 00:45 +0100
                          Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-21 04:35 -0500
                            Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 08:48 -0800
                              Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-22 00:12 -0800
                              Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 06:12 -0500
                                Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-22 04:30 -0800
                                  Re: Learning to code by reading code Geoff <geoff@invalid.invalid> - 2012-02-22 10:45 -0800
                                    Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-23 01:12 -0800
                                  Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-23 07:34 -0500
                                    Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-23 05:46 -0800
                                      Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-24 08:38 +0100
                                        Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-24 08:40 +0100
                                        Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-24 09:38 +0100
                                      Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-25 05:25 -0500
                                        Re: Learning to code by reading code Dombo <dombo@disposable.invalid> - 2012-02-25 12:50 +0100
                                        Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-25 06:13 -0800
                                          Re: Learning to code by reading code Gareth Owen <gwowen@gmail.com> - 2012-02-26 07:20 +0000
                        Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 08:23 +0000
                          Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 08:43 +0000
                            Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-21 04:47 -0500
                              Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 10:09 +0000
                                Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 05:38 -0500
                          Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-21 04:31 -0500
                            Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 10:05 +0000
                              Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-21 12:21 +0100
                              Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 06:04 -0500
                            Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-21 11:01 +0000
                              Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 05:59 -0500
                        Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 01:27 -0800
                    Re: Learning to code by reading code Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2012-02-20 22:25 +0100
                      Re: Learning to code by reading code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-26 08:47 +0000
                        Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-26 10:55 +0000
                    Re: Learning to code by reading code Nomen Nescio <nobody@dizum.com> - 2012-02-22 08:59 +0100
                      Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 05:59 -0500
                        Re: Learning to code by reading code Nomen Nescio <nobody@dizum.com> - 2012-02-22 13:47 +0100
                          Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-23 06:21 -0500
                    Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-22 00:08 -0800
              Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-19 03:54 -0500
                Re: Learning to code by reading code Stanley Rice <heconghui@gmail.com> - 2012-02-19 05:24 -0800
              Re: Learning to code by reading code Marco van de Voort <marcov@toad.stack.nl> - 2012-02-19 11:27 +0000
            Re: Learning to code by reading code (was: The way to read STL source code) Ebenezer <woodbrian77@gmail.com> - 2012-02-18 20:02 -0800
              Re: Learning to code by reading code (was: The way to read STL source code) 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-18 21:51 -0800
              Re: Learning to code by reading code (was: The way to read STL source code) "Bo Persson" <bop@gmb.dk> - 2012-02-19 16:10 +0100
            Re: The way to read STL source code Mark Elston <m.elston@advantest-ard.com> - 2012-02-21 16:40 -0800
      Re: The way to read STL source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-17 01:06 -0800
    Re: The way to read STL source code Goran <goran.pusic@gmail.com> - 2012-02-16 23:36 -0800
      Re: The way to read STL source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-17 01:12 -0800
        Re: The way to read STL source code Goran <goran.pusic@gmail.com> - 2012-02-17 03:57 -0800
          Re: The way to read STL source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-17 05:15 -0800
            Re: The way to read STL source code Goran <goran.pusic@gmail.com> - 2012-02-17 06:02 -0800
            Re: The way to read STL source code Stanley Rice <heconghui@gmail.com> - 2012-02-17 17:08 -0800
              Re: The way to read STL source code Dombo <dombo@disposable.invalid> - 2012-02-19 16:52 +0100
    Re: The way to read STL source code Krice <paulkp@mbnet.fi> - 2012-02-24 00:38 -0800
    Re: The way to read STL source code 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-25 10:46 -0800
      Re: The way to read STL source code 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-26 14:57 -0800
      Re: The way to read STL source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-27 03:02 -0800

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#14430 — Re: Learning to code by reading code

On Wed, 22 Feb 2012 04:30:54 -0800 (PST), Nick Keighley
<nick_keighley_nospam@hotmail.com> wrote:

>no. I see no contradiction. Machine code is validated as a side-effect
>of HLL validation. I've /never/ seen anyone inspect the assembler
>output of a compiler as a matter of course.

I don't do it very often anymore but I did it a lot in an embedded
system using a Microtec Research C compiler for Z80/Z180. It emitted
some code that thrashed around with the HL and DE registers, swapping
them circularly for about 4 instructions. Email to them with sample
code got me a phone call from the compiler maintainer and the compiler
was fixed that afternoon. Routine? Far from it, but checking the
product of the compiler's translation can sometimes produce insights.

[toc] | [prev] | [next] | [standalone]

#14447 — Re: Learning to code by reading code

On Feb 22, 6:45 pm, Geoff <ge...@invalid.invalid> wrote:
> On Wed, 22 Feb 2012 04:30:54 -0800 (PST), Nick Keighley
> <nick_keighley_nos...@hotmail.com> wrote:

Rod Pemberton wrote:
>> [...] So, you [NK] believe in code inspection of the HLL code, but
>> *not* the emitted assembly?  Well, I just don't know what to say about that
>> contradiction [...]

> >no. I see no contradiction. Machine code is validated as a side-effect
> >of HLL validation. I've /never/ seen anyone inspect the assembler
> >output of a compiler as a matter of course.
>
> I don't do it very often anymore but I did it a lot in an embedded
> system using a Microtec Research C compiler for Z80/Z180. It emitted
> some code that thrashed around with the HL and DE registers, swapping
> them circularly for about 4 instructions. Email to them with sample
> code got me a phone call from the compiler maintainer and the compiler
> was fixed that afternoon. Routine? Far from it, but checking the
> product of the compiler's translation can sometimes produce insights.

it's a matter of balance. I've looked at assmembler in the past and if
i suspected a compiler bug (or had some other good reason) I'd look at
it again. But it certainly isn't an every-day activity for either
myself /or/ for anyone I've worked with in recent years.

I suspect Mr Pemberton is trolling a bit. And I bite.

[toc] | [prev] | [next] | [standalone]

#14452 — Re: Learning to code by reading code

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
news:3f734b2b-2d8a-4c73-81e3-3c43e39e16f7@y10g2000vbn.googlegroups.com...
> On Feb 22, 11:12 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
...

> [...]
> If the HLL verifies then the machine code has been verified as a side
effect.

a) "Verifies" how?
b) No.  That just means that whatever was "verified" didn't trigger or run
into the error.

> > Is the code executed as part of these tests? I.e., confirmed,
> > but not confirmed on an "imaginary machine" ...
>
> yes the code is executed. [...]
>
...

> And I'll point out again you misquoted me on "imaginary
> machines". Stop doing this.

Huh?  What are you talking about misquoted?  In response to me saying one
needs to check the assembly output, you said:

NK> I don't think so. When I come across a novel
NK> language feature I like to think how it would
NK> be implemented. But I use an imaginary machine
NK> (or these days, C!).

For which, I asked this about the "imaginary machine":

RP> How do you confirm correctness of both high-level
RP> and low-level code with an imaginary machine?  Is
RP> your confirmation of correctness imaginary also? ...

From which you progressly migrated into real world testing of code that was
supposedly being tested somehow on an imaginary machine ...  That seems to
be this of the thread.

> > Wikipedia's DbC page mentions preconditions.
>
> and post-conditions?

That too, but I was mentioning, sarcastically, a real-world repeated
identical if() statement as DbC "pre-conditions".  They clearly weren't
coded with the concepts of DbC.  They were there to ensure that "wrong data"
didn't enter the "wrong part" of the program and become corrupted or cause
other hazardous unknowns.

> I'd say that was the over 500 identical cut-n-pasted if()
> [...]
...

> Machine code is validated as a side-effect of HLL validation.

Well, definately not for an imaginary machine ...

And, just because a program currently works correctly with the input sets
you've tried, doesn't mean it will later with a different data set or
different combination of user selections.  We ran into that issue all the
time on the 5MLoc program.  We ran extremely large datasets and tested and
retested every feature to the point of repugnance.  All that means is the
bug hasn't been discovered.  That bug can be in compiler output, or it can
be in the programmer's expectations about what the compiler should be doing,
but isn't, doesn't, or didn't.  Without verifying the emitted assembly does
what you expect the HLL code to do, how do you know it is?


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#14456 — Re: Learning to code by reading code

On Feb 23, 12:34 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
> news:3f734b2b-2d8a-4c73-81e3-3c43e39e16f7@y10g2000vbn.googlegroups.com...> On Feb 22, 11:12 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>


> > [...]
> > If the HLL verifies then the machine code has been verified as a side
> > effect.
>
> a) "Verifies" how?

um... "verify" n. to confirm the correctness of.

If the HLL is correct the machine code is correct (barring unobserved
side effects). Do these happen a lot?

> b) No.  That just means that whatever was "verified" didn't trigger or run
> into the error.

doesn't this apply to both HLL and machine code?

> > > Is the code executed as part of these tests? I.e., confirmed,
> > > but not confirmed on an "imaginary machine" ...
>
> > yes the code is executed. [...]
>
> > And I'll point out again you misquoted me on "imaginary
> > machines". Stop doing this.
>
> Huh?  What are you talking about misquoted?  In response to me saying one
> needs to check the assembly output, you said:
>
> NK> I don't think so. When I come across a novel
> NK> language feature I like to think how it would
> NK> be implemented. But I use an imaginary machine
> NK> (or these days, C!).

this is as an aid to understanding a novel language feature. I imagine
how it might be implemented. This isn't part of a verification
strategy.

> For which, I asked this about the "imaginary machine":
>
> RP> How do you confirm correctness of both high-level
> RP> and low-level code with an imaginary machine?

I don't. Like I said, it is used as an aid to understanding. Mental
scaffolding.

> Is
> RP> your confirmation of correctness imaginary also? ...
>
> From which you progressly migrated into real world testing of code that was
> supposedly being tested somehow on an imaginary machine ...  That seems to
> be this of the thread.

I never said I tested on an imaginary machine. Though I have done host
testing as part of the verification of a program destined to run on a
different target.

<snip>

> > Machine code is validated as a side-effect of HLL validation.
>
> Well, definately not for an imaginary machine ...
>
> And, just because a program currently works correctly with the input sets
> you've tried, doesn't mean it will later with a different data set or
> different combination of user selections.

this applies to all forms of testing. Hence walkthrus, inspection, DbC
etc.
Unit Test is supposed to be a little more resistant to this affect as
there is a systematic attempt to check all boundary conditions etc.

The onlt "fool proof" alternative is formal methods.

> We ran into that issue all the
> time on the 5MLoc program.  We ran extremely large datasets and tested and
> retested every feature to the point of repugnance.  All that means is the
> bug hasn't been discovered.  That bug can be in compiler output, or it can
> be in the programmer's expectations about what the compiler should be doing,
> but isn't, doesn't, or didn't.  Without verifying the emitted assembly does
> what you expect the HLL code to do, how do you know it is?

what makes you think verifying machine code is any easier than
verifying HLL code? How do I validate a mega-byte of HLL by looking at
the machine code?

[toc] | [prev] | [next] | [standalone]

#14472 — Re: Learning to code by reading code

"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:f327777d-fa31-4ef9-8d3a-3d4d25363ee9@db5g2000vbb.googlegroups.com...

>what makes you think verifying machine code is any easier than
>verifying HLL code? How do I validate a mega-byte of HLL by looking at
>the machine code?
i risk one answer
because my asm scale better than your hll
and it is easy to read?
depend how much difficult add the semantic of hlls languages
and how the algo are clear in the paper or in the mind of
who read

one thing i'm pretty sure it is all has to be read as
little instruction as a^=b or jump label

[toc] | [prev] | [next] | [standalone]

#14473 — Re: Learning to code by reading code

"io_x" <a@b.c.invalid> ha scritto nel messaggio 
news:4f473d62$0$1386$4fafbaef@reader2.news.tin.it...
> one thing i'm pretty sure it is all has to be read as
> little instruction as a^=b or jump label

one thing i'm pretty sure is there would be a way to see until
little easy instruction as a^=b or jump label

[toc] | [prev] | [next] | [standalone]

#14474 — Re: Learning to code by reading code

"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:4f473d62$0$1386$4fafbaef@reader2.news.tin.it...
> "Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
> news:f327777d-fa31-4ef9-8d3a-3d4d25363ee9@db5g2000vbb.googlegroups.com...
>
>>what makes you think verifying machine code is any easier than
>>verifying HLL code? How do I validate a mega-byte of HLL by looking at
>>the machine code?
> i risk one answer
> because my asm scale better than your hll
> and it is easy to read?

for example the unsigned type

unsigned  a, b, c;
than i make operations on a, b, c,
and so program a *set of machine* [machine == CPU]
follow the C standard...

if a, b, c has a size as 32 bit
uint32_t  a, b, c;
and operation on them are well definited
and program ONE machine [the sub cpu of 32 bit]

in other words: if program is difficult for just *one* machine
what make to think it is not exponential difficult to
a set of machines?

the same of above can be done for pointer when someone see
pointers as numbers: all is easier
and somethime easier means can be done

> depend how much difficult add the semantic of hlls languages
> and how the algo are clear in the paper or in the mind of
> who read
>
> one thing i'm pretty sure it is all has to be read as
> little instruction as a^=b or jump label

one thing i'm pretty sure it is there would be
one way to see all HLL code traslation until
little easy instruction as a^=b or jump label
or  a|=b

[toc] | [prev] | [next] | [standalone]

#14493 — Re: Learning to code by reading code

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
news:f327777d-fa31-4ef9-8d3a-3d4d25363ee9@db5g2000vbb.googlegroups.com...
> On Feb 23, 12:34 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
> > "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
> >
news:3f734b2b-2d8a-4c73-81e3-3c43e39e16f7@y10g2000vbn.googlegroups.com...>
...

> If the HLL is correct the machine code is correct [...]

This assumes the HLL code and machine code are 100% identical.  That assumes
the compiler is 100% perfect in it's translation.  That also assumes the
libraries are 100% perfect in their implementation.  The HLL code can be
100% correct syntactically and the generated machine code can be wrong.

> > [...] whatever was "verified" didn't trigger or run
> > into the error.
>
> doesn't this apply to both HLL and machine code?

If you can interpret the HLL code and you can compile it to machine code
too, then yes.  Otherwise, no, it only applies to the machine code since the
HLL can't be fully "verified" except by compiling it to machine code.

> > > Machine code is validated as a side-effect of HLL validation.
>
> > [...]
> > And, just because a program currently works correctly with
> > the input sets you've tried, doesn't mean it will later with a
> > different data set or different combination of user selections.
>
> this applies to all forms of testing. [...]

If you don't take issues here, why do you do so above?!

> what makes you think verifying machine code is any easier
> than verifying HLL code?

I didn't say it is.

> How do I validate a mega-byte of HLL by looking at
> the machine code?

By compiling and studying the output for all the language elements, type
conversions, etc you use to understand if your compiler is emitting them
correctly, or that your understanding of what the HLL code does is correct
in terms of the assembly.  You don't have study the entire output of a large
program.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#14495 — Re: Learning to code by reading code

Op 25-Feb-12 11:25, Rod Pemberton schreef:
> "Nick Keighley"<nick_keighley_nospam@hotmail.com>  wrote in message

>> How do I validate a mega-byte of HLL by looking at
>> the machine code?
>
> By compiling and studying the output for all the language elements, type
> conversions, etc you use to understand if your compiler is emitting them
> correctly, or that your understanding of what the HLL code does is correct
> in terms of the assembly.

Only for that particular case; especially with (aggressive) 
optimizations enabled there is not a simple mapping of language 
constructs to assembly instructions. Sometimes slight variations in the 
HLL code may cause the compiler to produce dramatically different output.

> You don't have study the entire output of a large
> program.

Studying the assembly output of just a small part of a program proves 
exactly nothing, nor does studying the assembly output of the entire 
program. Like a compiler might not correctly translate HLL to machine 
instructions, the processor may not necessarily execute the machine 
instructions correctly in all cases.

If you want to test a piece of software you test if it produces the 
correct responses given a set stimuli. Often it is a good idea to 
automate this process, especially for products with a long life-cycle. 
This is a lot cheaper and useful than manually inspecting the assembly 
output of a compiler. In the end the user doesn't give a rats ass about 
the machine instructions; he/she only cares if the software works correctly.

Personally I inspect the compiler output for only two reasons:
1. Improve my understanding what the compiler can optimize and what not. 
This has taught me that unlike popular belief code tweaks that make the 
code less readable doesn't make the code necessarily faster (often quite 
the contrary). Of course you always have to measure regardless.
2. I have a strong suspicion code does not execute correctly because of 
a compiler bug. For me this is something I do only as a last resort 
after confirming it is definitely not a bug in the HLL code (which is 
much more likely), consulting the language specification if necessary. 
In my experience the chances of being bitten by a compiler bug are very 
small. More often than not perceived compiler bugs are in reality caused 
by HLL code that has some undefined behavior and uninitialized 
variables. But compiler bugs do exist and are most likely to pop up when 
aggressive optimization settings are used.

When C++ was new to me studying the assembly output of the compiler did 
give me a better understanding of the language in a way. It helped me to 
better understand better why things are the way they are in the 
language, and what symptoms you can expect when there are certain flaws 
in the HLL code. It certainly gives me an edge compared to colleagues 
who are pretty clues less about how a compiler translates code to 
machine instructions, and to which the assembly output looks like a load 
of gibberish. That being said I wouldn't recommend it as the best way to 
learn a programming language.

[toc] | [prev] | [next] | [standalone]

#14496 — Re: Learning to code by reading code

On Feb 25, 10:25 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
> news:f327777d-fa31-4ef9-8d3a-3d4d25363ee9@db5g2000vbb.googlegroups.com...> On Feb 23, 12:34 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > wrote:
> > > "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
> news:3f734b2b-2d8a-4c73-81e3-3c43e39e16f7@y10g2000vbn.googlegroups.com...>


> > If the HLL is correct the machine code is correct [...]

you're a dissembling so and so aren't you? Every time you quote me I
have to check you got the quote right. What was written was:-

*********************************************
> > If the HLL verifies then the machine code has been verified as a side
> > effect.

> a) "Verifies" how?

um... "verify" n. to confirm the correctness of.

If the HLL is correct the machine code is correct (barring unobserved
side effects). Do these happen a lot?
*********************************************

You had trouble with "verifies" so I simplified it for you. It is
plain in context I'm talking about verification.

> This assumes the HLL code and machine code are 100% identical.

well yes. As far as the side effects of evaluation are concerned they
*are* identical. How can you execute the HLL without executing the
machine code?

> That assumes
> the compiler is 100% perfect in it's translation.

no. I assume compilers are very very good. I tend to truct the
implementors.

and no. Because testing the hLL will reveal potential compiler bugs.

> That also assumes the
> libraries are 100% perfect in their implementation.  The HLL code can be
> 100% correct syntactically and the generated machine code can be wrong.

library bugs are commoner than compiler bugs. But as above.

> > > [...] whatever was "verified" didn't trigger or run
> > > into the error.
>
> > doesn't this apply to both HLL and machine code?
>
> If you can interpret the HLL code and you can compile it to machine code
> too, then yes.  Otherwise, no, it only applies to the machine code since the
> HLL can't be fully "verified" except by compiling it to machine code.

many 9's close though.

> > > > Machine code is validated as a side-effect of HLL validation.
>
> > > [...]
> > > And, just because a program currently works correctly with
> > > the input sets you've tried, doesn't mean it will later with a
> > > different data set or different combination of user selections.
>
> > this applies to all forms of testing. [...]
>
> If you don't take issues here, why do you do so above?!

what?

> > what makes you think verifying machine code is any easier
> > than verifying HLL code?
>
> I didn't say it is.

so why do you recomemnd examining the machine code?
I really don't understand what you are getting at. From my point of
view, looking at the assmbler is another form of verification. I don't
see it as a useful or cost effective one.

> > How do I validate a mega-byte of HLL by looking at
> > the machine code?
>
> By compiling and studying the output for all the language elements, type
> conversions, etc you use to understand if your compiler is emitting them
> correctly,

ah! So you are essentially validating the compiler. I suspect high
levels of optimsation will render this useless. Like I've said the
rate of compiler bugs seems so low I leave that to compiler
developers. And so do most people I know.

> or that your understanding of what the HLL code does is correct
> in terms of the assembly.  You don't have study the entire output of a large
> program.

ok. Misunderstood you.

[toc] | [prev] | [next] | [standalone]

#14505 — Re: Learning to code by reading code

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

>> > If the HLL is correct the machine code is correct [...]
>
> you're a dissembling so and so aren't you? 

Pun of the year! (even if unintentional)

[toc] | [prev] | [next] | [standalone]

#14347 — Re: Learning to code by reading code

In comp.lang.c++ Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
> How many of the languages which have a language feature that is
> "missing" from C are compiled to C or once were?

  Obviously you could write an interpreter in C that interprets the
language you are trying to implement, and hey, you got the feature "in C".
The question is: Would it be *efficient*?

  Even if instead of an interpreter the original language is butchered
into an actual C program by an automaton, and even if the resulting
compiled program somewhat approaches the efficiency of the binary
produced by an actual compiler for that other language, the resulting
C code is usually completely unreadable and unusable by a human being.
In many cases you can forget about trying to write such constructs
directly in C by hand.

  Even then it would probably be hard to match the speed of an actual
compiler of the original language. Just take C++ exceptions, for instance.
I don't see any easy way to get the same effect in C without slowing
down the code.

[toc] | [prev] | [next] | [standalone]

#14349 — Re: Learning to code by reading code

In comp.lang.c++ Juha Nieminen <nospam@thanks.invalid> wrote:
>  Even if instead of an interpreter the original language is butchered
> into an actual C program by an automaton, and even if the resulting
> compiled program somewhat approaches the efficiency of the binary
> produced by an actual compiler for that other language, the resulting
> C code is usually completely unreadable and unusable by a human being.

  Oh, and I forgot to mention: Any safety of the original construct will
be completely lost when translated to C, which further makes it unusable
when writing C directly.

[toc] | [prev] | [next] | [standalone]

#14359 — Re: Learning to code by reading code

"Juha Nieminen" <nospam@thanks.invalid> wrote in message
news:4f435938$0$3083$7b1e8fa0@news.nbl.fi...
> In comp.lang.c++ Juha Nieminen <nospam@thanks.invalid> wrote:
> >  Even if instead of an interpreter the original language is butchered
> > into an actual C program by an automaton, and even if the resulting
> > compiled program somewhat approaches the efficiency of the binary
> > produced by an actual compiler for that other language, the resulting
> > C code is usually completely unreadable and unusable by a human being.
>
> Oh, and I forgot to mention: Any safety of the original construct will
> be completely lost when translated to C, which further makes it unusable
> when writing C directly.

The exact same can be said about compiling to assembly or machine code.
The type checking, i.e., "safety," is done by the compiler, not the compiler
output.  The compiler checks the syntax and parsing rules for errors.  Once
you have assembly or machine code, the "safety of the original construct" is
"completely lost".  The syntax and parsing rules are not encoded into the
compiled program.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#14362 — Re: Learning to code by reading code

In comp.lang.c++ Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
>> Oh, and I forgot to mention: Any safety of the original construct will
>> be completely lost when translated to C, which further makes it unusable
>> when writing C directly.
> 
> The exact same can be said about compiling to assembly or machine code.

  Which is one of the reasons why asm is seldom used directly. Exactly
my point.

> The type checking, i.e., "safety," is done by the compiler, not the compiler
> output.  The compiler checks the syntax and parsing rules for errors.  Once
> you have assembly or machine code, the "safety of the original construct" is
> "completely lost".  The syntax and parsing rules are not encoded into the
> compiled program.

  The original claim was that C supports everything that any other language
supports. Not true. C does not support most of the safety mechanisms that
other languages have.

[toc] | [prev] | [next] | [standalone]

#14409 — Re: Learning to code by reading code

"Juha Nieminen" <nospam@thanks.invalid> wrote in message
news:4f436d67$0$4364$7b1e8fa0@news.nbl.fi...
> In comp.lang.c++ Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
> >> Oh, and I forgot to mention: Any safety of the original construct will
> >> be completely lost when translated to C, which further makes it
> >> unusable when writing C directly.
> >
> > The exact same can be said about compiling to assembly or machine code.
>
>   Which is one of the reasons why asm is seldom used directly.

Asm is seldom used directly "for what" ... ?

I don't know what you're talking about here.

Assembly is still used directly by assembly programmers, and directly as the
output of most compilers.  There are only a handful of compilers that
directly emit machine language, e.g., OpenWatcom.  Those that don't emit
assembly typically emit C which when compiled by a C compiler then typically
emits assembly which when assembled by an assembler emits machine code.  So,
where is it that "asm seldom used directly"?

Were you simply trying to say that most assemblers don't support safe
programming features, like type checking, and therefore we use (or should
use) HLLs instead?  Ludicrous!  Some assemblers have such features if people
would just learn them and use them.  Personally, I use HLLs because I don't
have to keep track of a variable's location in my head, e.g., memory,
register, or stack.  I don't like playing "Where's Waldo?" when programming.

> > The type checking, i.e., "safety," is done by the compiler, not the
> > compiler output.  The compiler checks the syntax and parsing
> > rules for errors.  Once you have assembly or machine code, the
> > "safety of the original construct" is "completely lost".  The syntax
> > and parsing rules are not encoded into the compiled program.
>
> The original claim was that C supports everything that any other
> language supports. Not true. C does not support most of the safety
> mechanisms that other languages have.

Sure it does.  Don't use the unsafe features:

a) There is only one instance where I've ever used a goto in C.  That was
for clarity.  Unstructured control-flow is available in C, but one does not
have to use it.  Unchecked pointers are available in C, but one does not
have to them either.

b) That's what languages that emit C do.  That's what MISRA C or Safer C do.
Or, you can create a new more safe C syntax, like C derivative such as Java
do.

If you're interested in which languages emit C or more on language success,
here are a few links to some of my other c.l.m. posts:
http://groups.google.com/group/comp.lang.misc/msg/b48b2f5abe7cff07
http://groups.google.com/group/comp.lang.misc/msg/a8e78f82691706cb
http://groups.google.com/group/comp.lang.forth/msg/47c602f348f362f6


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#14356 — Re: Learning to code by reading code

"Juha Nieminen" <nospam@thanks.invalid> wrote in message
news:4f43548d$0$3083$7b1e8fa0@news.nbl.fi...
> In comp.lang.c++ Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
...

> > How many of the languages which have a language feature that is
> > "missing" from C are compiled to C or once were?
>
> Obviously you could write an interpreter in C that interprets the
> language you are trying to implement, and hey, you got the feature
> "in C".

Yes, you could do that: write an interpreter.  However, it's probably better
to just emit C code for it directly ...

> The question is: Would it be *efficient*?

No, it wouldn't.  There is no such thing as an "*efficient*" interpreter as
compared to compiled native code.  There are two fundamental problems with
interpreters that can't be overcome: 1) they reimplement the mechanisms of
assembly language which slows things down alot 2) they can't optimize and
compile code sequences which dramatically slows down loops and other
control-flow.

> Even if instead of an interpreter the original language is butchered
> into an actual C program by an automaton, [...]

Yes, I agree, programmatic code conversion is rarely human readable.

> [...] and even if the resulting compiled program somewhat
> approaches the efficiency of the binary produced by an
> actual compiler for that other language,  [...]

They usually do produce efficient code.  Sometimes it's actually better than
human coded code because the other language uses low level constructs
which can be optimized more readily.

> [...] the resulting C code is usually completely unreadable
> and unusable by a human being.

True, but if you coded that feature yourself, it doesn't have to be
coded as "butchered" code.

> Even then it would probably be hard to match the speed of an actual
> compiler of the original language.

I don't believe that.  C has had some of the most intensive research into
language optimizations.  Other languages just haven't had the time and
research put into them.

> Just take C++ exceptions, for instance. I don't see any easy way
> to get the same effect in C without slowing down the code.

Sorry, I'm not familiar with C++.  However, if exceptions interrupt the
normal program flow like signals do, then it'll slow down the code purely
due to whatever save-restore state mechanism is used to handle the
exception.  That requires substantial overhead in assembly.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#14361 — Re: Learning to code by reading code

In comp.lang.c++ Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
>> Even then it would probably be hard to match the speed of an actual
>> compiler of the original language.
> 
> I don't believe that.

  Why not? It's not very hard to believe. If the language has no support
for a certain higher-level concept, then the compiler cannot use that
concept to perform optimizations.

  You cannot express everything in C that can be expressed in asm.
(You can probably achieve the same functionality, but you cannot achieve
the same efficiency in every single case.)

>  C has had some of the most intensive research into
> language optimizations.

  Yes, into *C* language optimizations, not other languages. What C does
not support as a concept the C compiler cannot optimize.

>> Just take C++ exceptions, for instance. I don't see any easy way
>> to get the same effect in C without slowing down the code.
> 
> Sorry, I'm not familiar with C++.  However, if exceptions interrupt the
> normal program flow like signals do, then it'll slow down the code purely
> due to whatever save-restore state mechanism is used to handle the
> exception.  That requires substantial overhead in assembly.

  Nope. That's the genius in C++ exceptions: Support for exceptions does
not slow down the program in any way (compared to compiling the program
without support for exceptions). (It was, AFAIK, in fact a requirement
by the standardization committee, that exceptions would be added to the
standard only if it's possible to support them without compromising the
speed of the program. It turns out that it's possible.)

  (Of course *throwing* an exception has overhead, but that's to be expected.
Exceptions are designed to be used to handle fatal errors, not for normal
operation. The main point is that when no exceptions are thrown, the code
is in no way slower than eg. the equivalent C program would be, even though
exceptions are supported and could be thrown at any moment, at any point
in the code.)

[toc] | [prev] | [next] | [standalone]

#14366 — Re: Learning to code by reading code

On 21 Feb 2012 10:05:56 GMT, Juha Nieminen wrote:

> Exceptions are designed to be used to handle fatal errors, not for normal
> operation.

No, they are for *exceptional* states. Such states are by no means fatal.
E.g. neither reading beyond file end, nor getting a numeric overflow are
fatal.

It is expected that exceptions are used to indicate states which are not so
frequent, so that the overhead caused the exception propagation could be
minor.

> The main point is that when no exceptions are thrown, the code
> is in no way slower than eg. the equivalent C program would be, even though
> exceptions are supported and could be thrown at any moment, at any point
> in the code.)

True, but even with exceptions thrown, the code may still be faster. Let us
consider an exception used to indicate the file end. Without an exception
the end file condition is tested twice per each file item to read. First
this is done in the subprogram reading the item. Then the check is repeated
by the caller when it tests the return code. A design that throws an
exception would check it only once, and thus become more efficient the
larger the file is.

Surely, it is theoretically possible to beat the performance of this
design, but at the cost of global optimization or else dropping read
subprogram and manually inserting equivalent I/O all over the code...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#14412 — Re: Learning to code by reading code

"Juha Nieminen" <nospam@thanks.invalid> wrote in message
news:4f436c84$0$4364$7b1e8fa0@news.nbl.fi...
> In comp.lang.c++ Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
> >> Even then it would probably be hard to match the speed of an actual
> >> compiler of the original language.
> >
> > I don't believe that.
>
>   Why not?

Well, I stated why.  It's the part about the research into and
implementation of optimizations.

> It's not very hard to believe. If the language has no support
> for a certain higher-level concept, then the compiler cannot use
> that concept to perform optimizations.

So, even though every "Turing complete" language can be expressed in terms
of an OISC, none of them can optimize a higher-level concept that is not
designed into in the high-level language?  Do they actually do any
optimization at all according to you?  You do understand that no
architecture executes the higher-level concept, yes?  I.e., they all execute
the optimized low-level assembly created for those high level concepts
whether designed into the language or not ...  In theory, any equivalent
program, no matter what "Turing complete" language is used, when translated
to an OISC and optimized, should produce the exact same program, entirely
independent of whatever high-level concepts that language has or doesn't.
Do you agree?

OISC
http://en.wikipedia.org/wiki/One_instruction_set_computer

> You cannot express everything in C that can be expressed in asm.

There is a sharp cutoff between what you can and can't express in C that is
equivalent to assembly.  C maps onto basic or generic assembly extremely
well, especially on 8-bit byte, contiguous memory, generic integer,
machines.  The major impediment is some of the type checking introduced with
ANSI C.  C captures nearly all of the functionality present in early 8-bit
microprocessors, except the carry flag, rotates, etc.  However, using that
functionality may require a few casts or having a chart of the type
conversion rules so you can convert types legally.  With x86, you generally
can't generate the more specialized or modern assembly instructions, e.g.,
SMM, MMX, PM, etc without inline assembly.  You may also some have
issues with DSPs or RISC instruction sets fitting well with C.  Of course,
word-sized machines were known to be a problem for C from the start.

> (You can probably achieve the same functionality, but
> you cannot achieve the same efficiency in every single case.)

It depends on what assembly functionality you're referring too.

> >  C has had some of the most intensive research into
> > language optimizations.
>
> Yes, into *C* language optimizations, not other languages.
> What C does not support as a concept the C compiler
> cannot optimize.

If it's expressed as C, it sure can!  That's what C compiler optimization
does.

What you, perhaps, intended to say is that if C language does not support a
certain concept, then the C compiler might not optimize it as effectively as
a native language compiler with aggressive optimization for that concept.
That could be true, but doesn't have to be.  See OISC comments above.

> >> Just take C++ exceptions, for instance. I don't see any easy way
> >> to get the same effect in C without slowing down the code.
> >
> > Sorry, I'm not familiar with C++.  However, if exceptions interrupt the
> > normal program flow like signals do, then it'll slow down the code
> > purely due to whatever save-restore state mechanism is used to handle
> > the exception.  That requires substantial overhead in assembly.
>
> Nope. That's the genius in C++ exceptions: Support for exceptions does
> not slow down the program in any way (compared to compiling the program
> without support for exceptions). (It was, AFAIK, in fact a requirement
> by the standardization committee, that exceptions would be added to the
> standard only if it's possible to support them without compromising the
> speed of the program. It turns out that it's possible.)
>
> (Of course *throwing* an exception has overhead, but that's to be
> expected. Exceptions are designed to be used to handle fatal errors,
> not for normal operation. The main point is that when no exceptions
> are thrown, the code is in no way slower than eg. the equivalent C
> program would be, even though exceptions are supported and could
> be thrown at any moment, at any point in the code.)

So, if an exception is thrown, C++ is slows downs due to the overhead.  How
is that any different from a signal in C?  How is that any different to me
stating there is substantial overhead present in assembly due to
save-restore state mechanism?  So, your comments here seem fine to me,
except I don't get the "Nope."


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.c++

csiph-web