Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #14135 > unrolled thread
| Started by | Stanley Rice <heconghui@gmail.com> |
|---|---|
| First post | 2012-02-16 23:18 -0800 |
| Last post | 2012-02-27 03:02 -0800 |
| Articles | 20 on this page of 90 — 23 participants |
Back to article view | Back to comp.lang.c++
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 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-02-20 05:09 -0800 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <c2e8b3ce-b516-4693-8cdb-244c17436a12@gi10g2000vbb.googlegroups.com> |
| In reply to | #14322 |
On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:66f82f8c-88e3-4764-8709-3b2fad575c79@y38g2000yqb.googlegroups.com...
> On Feb 19, 7:17 pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> > Nick Keighley wrote:
> > > On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > > wrote:
> > >> "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
> > >>news:assembly-20120219023621@ram.dialup.fu-berlin.de...
> > >>> "Rod Pemberton" <do_not_h...@noavailemail.cmm> writes:
> > >>>> learning how that language is converted to assembly [is important]
> > Each foo(), *foo, foo[i], ++foo, foo++, and for that matter, '{' and '}' has
> > in my mind very specific implications and costs.
[...]
> > As I type or read each
> > 'if', 'switch', 'for', 'try', 'catch', and 'return', I hold in mind on a
> > subconscious level the underlying assembler, albeit on a broad generalized
> > model.
[...]
> To me C is the machine at the bottom.
>
> #this is io_x
> #C can not be the one machine language.
probably not ideal. Trying to write an interpreter for another
language has taught me that C is quite awkward for some things. I want
computed gotos!
> #it will be the language one machine if it has no Undefinited Behaviour,
not really relevent. Some assembly languages and even machine codes
have "undefined behaviour". Provide you stick to well defined
operations you have well defined semantics.
> #and type of know size, and operation on these type all the same for all PCs
not relevent
> #and i think a way to reach the stack it[C] use for call functions
> #and for save variable in the function preamble...
can't see the need. For an interprter I hand built the list of
environments ("the stack")
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2012-02-20 15:11 +0100 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <4f4253a0$0$1388$4fafbaef@reader1.news.tin.it> |
| In reply to | #14324 |
"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:c2e8b3ce-b516-4693-8cdb-244c17436a12@gi10g2000vbb.googlegroups.com...
On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel
> messaggionews:66f82f8c-88e3-4764-8709-3b2fad575c79@y38g2000yqb.googlegroups.com...
> On Feb 19, 7:17 pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> > Nick Keighley wrote:
> > > On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > > wrote:
> > >> "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
> > >>news:assembly-20120219023621@ram.dialup.fu-berlin.de...
> > >>> "Rod Pemberton" <do_not_h...@noavailemail.cmm> writes:
> > >>>> learning how that language is converted to assembly [is important]
> > Each foo(), *foo, foo[i], ++foo, foo++, and for that matter, '{' and '}' has
> > in my mind very specific implications and costs.
[...]
> > As I type or read each
> > 'if', 'switch', 'for', 'try', 'catch', and 'return', I hold in mind on a
> > subconscious level the underlying assembler, albeit on a broad generalized
> > model.
[...]
> To me C is the machine at the bottom.
>
> #this is io_x
> #C can not be the one machine language.
probably not ideal. Trying to write an interpreter for another
language has taught me that C is quite awkward for some things. I want
computed gotos!
> #it will be the language one machine if it has no Undefinited Behaviour,
not really relevent. Some assembly languages and even machine codes
have "undefined behaviour". Provide you stick to well defined
operations you have well defined semantics.
#i'm not agree, a machine has to execute its statement with no UBs
#is one assembly language has UBs for me is not an assembly and can not
#to pilot one cpu
> #and type of know size, and operation on these type all the same for all PCs
not relevent
#it is relevant, each basic oparation for 8,16,32,64,...
#size has to be fully portable
> #and i think a way to reach the stack it[C] use for call functions
> #and for save variable in the function preamble...
can't see the need. For an interprter I hand built the list of
environments ("the stack")
#i see the need because i think C work ok for many time just for the way
#the stack it use
#as someone other had to say, stack is fundamental in the programming area
#but i can wrong on all, because i'm little as a little bird :)
#and i drank some rum for now [but i not drink too much]
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-02-20 07:39 -0800 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <cb0f1708-1f07-4564-97f2-dce839c9a630@do4g2000vbb.googlegroups.com> |
| In reply to | #14328 |
On Feb 20, 2:11 pm, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:c2e8b3ce-b516-4693-8cdb-244c17436a12@gi10g2000vbb.googlegroups.com...
> On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote:
> > "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel
> > messaggionews:66f82f8c-88e3-4764-8709-3b2fad575c79@y38g2000yqb.googlegroups.com...
> > On Feb 19, 7:17 pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> > > Nick Keighley wrote:
> > > >>>> learning how that language is converted to assembly [is important]
> > > Each foo(), *foo, foo[i], ++foo, foo++, and for that matter, '{' and '}' has
> > > in my mind very specific implications and costs.
[...]
> > To me C is the machine at the bottom. [the implementation machine]
Note I'm only talking about C/Assembler as the language to define high
level semantics. I think assembler is a poor way to describe
semantics. It's too verbose and too far away from HLLs. It's also
hellish to understand.
> > #this is io_x
> > #C can not be the one machine language.
>
> probably not ideal. Trying to write an interpreter for another
> language has taught me that C is quite awkward for some things. I want
> computed gotos!
>
> > #it will be the language one machine if it has no Undefinited Behaviour,
>
> not really relevent. Some assembly languages and even machine codes
> have "undefined behaviour". Provide you stick to well defined
> operations you have well defined semantics.
>
> #i'm not agree, a machine has to execute its statement with no UBs
> #is one assembly language has UBs for me is not an assembly and can not
> #to pilot one cpu
sadly you are trumped by reality. The Z80 (and I believe 8080) had
unused op-codes. By tracing the logic of how instructions were build
you could deduce what these op-codes should do. And on many CPUs they
did exactly what you expected. But I suspect the manufacturers had
damn good reason for not including these instructions so you'd have to
be mad to use them.
I'm sure plenty of things give UB. Divide by zero, large shifts,
contention between coprocessors.
> > #and type of know size, and operation on these type all the same for all PCs
>
> not relevent
>
> #it is relevant, each basic oparation for 8,16,32,64,...
> #size has to be fully portable
(a) not for general programming
(b) if you *really* need them then hide them behind typedefs
(c) not relevent when discussign HLL semantics
> > #and i think a way to reach the stack it[C] use for call functions
> > #and for save variable in the function preamble...
don't need this for HLL semantics
> can't see the need. For an interprter I hand built the list of
> environments ("the stack")
>
> #i see the need because i think C work ok for many time just for the way
> #the stack it use
the C Standard doesn't insist on a stack. You can implement a stack
without access to SP or whatever an I86 calls it.
> #as someone other had to say, stack is fundamental in the programming area
but it doesn't have to be implemented in hardware. And some languages
don't follow simple semantics in procedure calls
<snip>
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2012-02-20 04:14 -0500 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <jht2uv$qnq$1@speranza.aioe.org> |
| In reply to | #14286 |
"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message news:d3b454ac-ae8e-4bd6-b67e-2e8e4050f849@w4g2000vbc.googlegroups.com... > On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> > wrote: ... > But I use an imaginary machine [...] > How do you confirm correctness of both high-level and low-level code with an imaginary machine? Is your confirmation of correctness imaginary also? ... That's one of the problems with the ANSI and ISO C specifications: it doesn't specify a working machine model. Without it, there is no reference working version of C that other implementations can be compared against. Without it, everything in the specifications is open to interpretation as to accuracy. That's the major problem that plagues the pedants on comp.lang.c. Each of them has their own model in their head of how C works and what the English words and phrases in the C standards mean. The British frequently have a different understanding of "either-or" versus Americans. It seems that not one of the pedants has ever programmed in assembly or believe they need to. None have read "The C Rationale", or read historical works by the C creators like "The Development of the C Language" or "Portability of C Programs and the UNIX System" or "The C Language Calling Sequence" etc which explain what C is supposed to do and make reference to assembly. If they did, none of them would ever argue against the understanding that C is built upon assembly and assembly is needed to fully understand C. Forth programmers hate the fact that their early specifications did specify a machine model. The problem wasn't that they specified a model, but they specified a very narrow model that wasn't able to adapt, or had radical changes in the following specification. But, that is far better than not specifying one at all. Many Forths were able to comply very accurately with their machine models. That allowed Forth to be widely implemented. Today, a couple of the early specifications are loved, and still used while a couple are hated. > (or these days, C!). > I'm not familiar with the C! language. Did you mean the C language? Perhaps you meant C# language? It seems that Wikipedia, Esolangs, nor Google or Yahoo, will find anything on C! or C exclamation language ... HOPL is inaccessible for some reason. However, if C! is a C derivative, it most likely inherited the basic functionality that a programmer needs to know. Most C derivative languages have kept that functionality because it has become standard due to microprocessors. > [...] but I can't see the utility in converting chunks of > C++ (or scheme or Haskell)into Z80 assembler. Yes, converting C++ for ARM to Z80 to understand how a HLL is converted to assembly would be questionable ... You'd want to study the ARM assembly code generated for C++. They need to understand how a HLL is converted to the assembly for their platform. They need to know how basic language constructs are converted to assembly, e.g., pointers, control-flow, procedures or function calls, etc. > > Many assembly languages > > are very similar. Microprocessors standardized on > > certain concepts around 1974 or so, e.g., 8-bit bytes > > for ASCII and EBCDIC, contiguous memory, pointer > > size equivalent to integer size, typeless integers, etc. > > but many C programmers (and maybe C++ programmers) > assume these are inviolate laws! They end up writing horribly > unportable programs for no reason except intellectual laziness > and lack of imagination about hardware engineers > (and compiler writers) might do. > > Your concentration on assembly code encourages this (naff) > type of coding. Ok, this is the same BS portable C argument that plagues comp.lang.c thought ... The first inherent problem with that argument is that microprocessors have standardized on a basic computing architecture. Nearly all computing platforms today use that architecture either because they are microprocessor based or because they use the same hardware, e.g., memory. They standardized way back around 1974. Mainframes followed suit slightly later. What that means is that almost no one today - or in the past two decades for that matter - has access to obscure, obsoleted, perverse platforms - or other platforms that *NEVER* shouldv'e have been used to create the ANSI C standard in the first place - where "portability" of C or C++ is actually needed. Have you ever had access to a non-emulated EBCDIC platform in your entire lifetime? (No.) Have you ever had access to a 16-bit byte platform in your entire lifetime? (No.) Have you ever had access to a 9-bit character platform in your entire lifetime? (No.) So, like it or not, it's entirely up to the users of obscure platforms to fix the "non-portable" nature of C code for their platforms. The second inherent problem with that argument is even C that is specification compliant is truly only 30% portable. And, that again is due to standardization of microprocessors on 8-bit bytes for ASCII or EBCDIC, contiguous memory, two's complement integers, generic integers so pointers are the same size, etc. Another 50% of C can be made to work correctly, but it's not portable by default. The compiler has to make it work. And, 20% of C is just non-portable. IIRC, you were on c.l.c, so I shouldn't have to mention stuff like setjmp, signals, buffering, POSIX based file I/O, etc. > > Many HLL compilers, e.g., for C, produce the nearly the same > > code but adjusted for different platforms. But, it's still the > > programmer's responsibility to understand what that HLL > > code is producing for their specific tools. > > nope. I get on just fine not knowing what code my HLL is producing. Then, I'd quess you won't get fired for producing faulty code either ... So, that qualifies you as either a novice or hobbyist. (Yes, I suspect you probably aren't ...) A professional would do so as a matter of course. How do you know your compiler is compliant with a specification, or your compiler accurately implements what you expect your code to do? Testing only? What if you missed something you could've caught had you simply just read the assembly? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> |
|---|---|
| Date | 2012-02-20 11:14 +0100 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <19pj0ujxkl4ba.kza32kqs2xvx$.dlg@40tude.net> |
| In reply to | #14309 |
On Mon, 20 Feb 2012 04:14:15 -0500, Rod Pemberton wrote: > "Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message > news:d3b454ac-ae8e-4bd6-b67e-2e8e4050f849@w4g2000vbc.googlegroups.com... >> On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> >> wrote: > ... > >> But I use an imaginary machine [...] > > How do you confirm correctness of both high-level and low-level code with an > imaginary machine? Huh, the whole idea of a correctness proof is to do it *before* running the code. You need no machine for that. > Is your confirmation of correctness imaginary also? ... As any confirmation is. Moreover, such imaginary confirmations are much stronger than any tests. Because they hold not only for a concrete machine and a concrete run, but for any machine and any run. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-02-20 02:49 -0800 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <2bc2a617-e283-44c7-9fd3-63d2887b896e@y10g2000vbn.googlegroups.com> |
| In reply to | #14309 |
On Feb 20, 9:14 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> wrote: > "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message > news:d3b454ac-ae8e-4bd6-b67e-2e8e4050f849@w4g2000vbc.googlegroups.com...> On Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> > > But I use an imaginary machine [...] > > How do you confirm correctness of both high-level and low-level code with an > imaginary machine? How do you "confirm correctness" by translating it into I86 assembler? to me "correctness" is a mathematical property. And if its good enough for Knuth... > Is your confirmation of correctness imaginary also? ... code inspection, DbC, unit test > That's one of the problems with the ANSI and ISO C specifications: it > doesn't specify a working machine model. that is one of it's major strengths. Though I've read a few language definitions in my time and *none* of them went anywhere near the bare metal. > Without it, there is no reference > working version of C that other implementations can be compared against. there is a clear definition of the semantics of each primitive. Luckily uncontaminaed by any particular implementation. We are beginning to repeat ourselves and making no progress in convincing each other. I've made my points. Re-read my previous posts if wish for reiteration. [assume massive snippage] > [...] None have read "The C Rationale", I have! lovely document. <snip> > [a Clike language] most likely inherited the basic > functionality that a programmer needs to know. exceptions, closures, continuations, modads, lost of stuff C doesn't provide. <snip> > > > Many assembly languages > > > are very similar. Microprocessors standardized on > > > certain concepts around 1974 or so, e.g., 8-bit bytes > > > for ASCII and EBCDIC, contiguous memory, pointer > > > size equivalent to integer size, typeless integers, etc. > > > but many C programmers (and maybe C++ programmers) > > assume these are inviolate laws! They end up writing horribly > > unportable programs for no reason except intellectual laziness > > and lack of imagination about hardware engineers > > (and compiler writers) might do. > > > Your concentration on assembly code encourages this (naff) > > type of coding. > > Ok, this is the same BS portable C argument that plagues comp.lang.c > thought ... > > The first inherent problem with that argument is that microprocessors have > standardized on a basic computing architecture. Nearly all computing > platforms today use that architecture either because they are microprocessor > based or because they use the same hardware, e.g., memory. They > standardized way back around 1974. Mainframes followed suit slightly later. > What that means is that almost no one today - or in the past two decades for > that matter - has access to obscure, obsoleted, perverse platforms - or > other platforms that *NEVER* shouldv'e have been used to create the ANSI C > standard in the first place - where "portability" of C or C++ is actually > needed. if in the following by platform you mean hardware then in many cases "yes I have used such things". But if by platform you mean "have I programmed in C on these things" then "no" > Have you ever had access to a non-emulated EBCDIC platform in your > entire lifetime? (No.) but I've encountered none ASCII character sets. > Have you ever had access to a 16-bit byte platform > in your entire lifetime? (No.) yes. And used HLLs on them. > Have you ever had access to a 9-bit > character platform in your entire lifetime? (No.) I've encountered 5 and 6 bit character sets. I've used 24 bit machines. I've used 1's complement machines. <snip> > > > [...] it's [...] the > > > programmer's responsibility to understand what that HLL > > > code is producing for their specific tools. > > > nope. I get on just fine not knowing what code my HLL is producing. > > Then, I'd quess you won't get fired for producing faulty code either ... > So, that qualifies you as either a novice or hobbyist. (Yes, I suspect you > probably aren't ...) A professional would do so as a matter of course. no. I known plenty of professional progarmmers and vanishingly few of them look at the assembler. Most would laugh at the idea. > How > do you know your compiler is compliant with a specification, or your > compiler accurately implements what you expect your code to do? > Testing only? What if you missed something you could've caught had you > simply just read the assembly? in my experience compiler bugs are very rare
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2012-02-20 13:02 +0100 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <4f42355e$0$1380$4fafbaef@reader2.news.tin.it> |
| In reply to | #14318 |
"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio news:2bc2a617-e283-44c7-9fd3-63d2887b896e@y10g2000vbn.googlegroups.com... On Feb 20, 9:14 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> wrote: > "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message > news:d3b454ac-ae8e-4bd6-b67e-2e8e4050f849@w4g2000vbc.googlegroups.com...> On > Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> > > But I use an imaginary machine [...] > > How do you confirm correctness of both high-level and low-level code with an > imaginary machine? How do you "confirm correctness" by translating it into I86 assembler? to me "correctness" is a mathematical property. #io_x in his ot language #balle; non puoi dimostrare la correttezza matematica di una espressione #che ha diversi risultati dipendendo dalla macchina effettiva in cui gira... And if its good enough for Knuth... > Is your confirmation of correctness imaginary also? ... code inspection, DbC, unit test ..... > Then, I'd quess you won't get fired for producing faulty code either ... > So, that qualifies you as either a novice or hobbyist. (Yes, I suspect you > probably aren't ...) A professional would do so as a matter of course. no. I known plenty of professional progarmmers and vanishingly few of them look at the assembler. Most would laugh at the idea. #so they program what? not a machine, a machine need a precise language #pheraps they program their imaginary machine != every machine in this planet
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-02-20 05:18 -0800 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <cd0da372-19f5-4867-86df-46a3e580e904@18g2000yqe.googlegroups.com> |
| In reply to | #14321 |
On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote: > "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:2bc2a617-e283-44c7-9fd3-63d2887b896e@y10g2000vbn.googlegroups.com... > On Feb 20, 9:14 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> > > "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message > >news:d3b454ac-ae8e-4bd6-b67e-2e8e4050f849@w4g2000vbc.googlegroups.com...> On > > Feb 19, 8:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> > > > But I use an imaginary machine [...] [if I do insist on compilign to machine code] > > How do you confirm correctness of both high-level and low-level code with an > > imaginary machine? > > How do you "confirm correctness" by translating it into I86 assembler? > to me "correctness" is a mathematical property. > > #io_x in his ot language > #balle; non puoi dimostrare la correttezza matematica di una espressione > #che ha diversi risultati dipendendo dalla macchina effettiva in cui gira... english please > And if its good enough for Knuth... > > > Is your confirmation of correctness imaginary also? ... > > code inspection, DbC, unit test > > ..... > > > Then, I'd quess you won't get fired for producing faulty code either ... > > So, that qualifies you as either a novice or hobbyist. (Yes, I suspect you > > probably aren't ...) A professional would do so as a matter of course. > > no. I known plenty of professional progarmmers and vanishingly few of > them look at the assembler. Most would laugh at the idea. > > #so they program what? they program in C (or C++ or whatever) > not a machine, a machine need a precise language > #pheraps they program their imaginary machine != every machine in this planet quarks. it's quarks all the way down
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-02-20 13:53 +0000 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <jhtja2$hm2$1@dont-email.me> |
| In reply to | #14323 |
"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message news:cd0da372-19f5-4867-86df-46a3e580e904@18g2000yqe.googlegroups.com... > On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote: >> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel >> messaggionews:2bc2a617-e283-44c7-9fd3- >> How do you "confirm correctness" by translating it into I86 assembler? >> to me "correctness" is a mathematical property. >> >> #io_x in his ot language >> #balle; non puoi dimostrare la correttezza matematica di una espressione >> #che ha diversi risultati dipendendo dalla macchina effettiva in cui >> gira... > > english please As I understood it: "Nonsense; you can't demonstrate the mathematical correction of an expression that has different results depending on the machine in which it runs". Although since that almost makes sense, it might not be quite right.. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-02-21 01:32 -0800 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <539cbcaa-e2ae-40d3-adde-e347bf18d9c5@ge5g2000vbb.googlegroups.com> |
| In reply to | #14327 |
On Feb 20, 1:53 pm, "BartC" <b...@freeuk.com> wrote: > "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message > > news:cd0da372-19f5-4867-86df-46a3e580e904@18g2000yqe.googlegroups.com... > > > On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote: > >> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel > >> messaggionews:2bc2a617-e283-44c7-9fd3- > >> How do you "confirm correctness" by translating it into I86 assembler? > >> to me "correctness" is a mathematical property. > > >> #io_x in his ot language > >> #balle; non puoi dimostrare la correttezza matematica di una espressione > >> #che ha diversi risultati dipendendo dalla macchina effettiva in cui > >> gira... > > > english please > > As I understood it: "Nonsense; you can't demonstrate the mathematical > correction of an expression that has different results depending on the > machine in which it runs". and so? If you have a clear model of each machine then you perhaps prove it would work on all of them. I really not sure what your point is. The C abstract seems a reasonable thing to try and prove things for. (Ok might be a bit messy) > Although since that almost makes sense, it might not be quite right..
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2012-02-21 16:16 +0100 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <4f43b46f$0$1379$4fafbaef@reader2.news.tin.it> |
| In reply to | #14357 |
"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio news:539cbcaa-e2ae-40d3-adde-e347bf18d9c5@ge5g2000vbb.googlegroups.com... On Feb 20, 1:53 pm, "BartC" <b...@freeuk.com> wrote: > "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message > > news:cd0da372-19f5-4867-86df-46a3e580e904@18g2000yqe.googlegroups.com... > > > On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote: > >> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel > >> messaggionews:2bc2a617-e283-44c7-9fd3- > >> How do you "confirm correctness" by translating it into I86 assembler? > >> to me "correctness" is a mathematical property. > > >> #io_x in his ot language > >> #balle; non puoi dimostrare la correttezza matematica di una espressione > >> #che ha diversi risultati dipendendo dalla macchina effettiva in cui > >> gira... > > > english please > > As I understood it: "Nonsense; you can't demonstrate the mathematical > correction of an expression that has different results depending on the > machine in which it runs". and so? If you have a clear model of each machine then you perhaps prove it would work on all of them. I really not sure what your point is. The C abstract seems a reasonable thing to try and prove things for. (Ok might be a bit messy) #you have to say just what a machine is... #one has to program only one machine #or the one machine is a subMachine of the machine #and not a set of machines or cpus #but #if all cpu have register of 32 bits with usual 32 bit #jump operation on code #it would be possible programm all these cpu in the subcpu #of 32 bit as it is one portable cpu, as just one machine > Although since that almost makes sense, it might not be quite right..
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-02-21 08:40 -0800 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <b94c8ec2-96fa-43e2-a752-394e1f533993@9g2000vbq.googlegroups.com> |
| In reply to | #14378 |
On Feb 21, 3:16 pm, "io_x" <a...@b.c.invalid> wrote: > "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:539cbcaa-e2ae-40d3-adde-e347bf18d9c5@ge5g2000vbb.googlegroups.com... > On Feb 20, 1:53 pm, "BartC" <b...@freeuk.com> wrote: > > "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message > >news:cd0da372-19f5-4867-86df-46a3e580e904@18g2000yqe.googlegroups.com... > > > On Feb 20, 12:02 pm, "io_x" <a...@b.c.invalid> wrote: > > >> How do you "confirm correctness" by translating it into I86 assembler? > > >> to me "correctness" is a mathematical property. > > > >> #io_x in his ot language > > >> #balle; non puoi dimostrare la correttezza matematica di una espressione > > >> #che ha diversi risultati dipendendo dalla macchina effettiva in cui > > >> gira... > > > > english please > > > As I understood it: "Nonsense; you can't demonstrate the mathematical > > correction of an expression that has different results depending on the > > machine in which it runs". > > and so? If you have a clear model of each machine then you perhaps > prove it would work on all of them. I really not sure what your point > is. The C abstract seems a reasonable thing to try and prove things > for. (Ok might be a bit messy) A better answer from me would have been "so don't do that. Use a stable abstract machine to do do your verification of correctness on." And I'm not sure an I86 qualifies as such a stable machine. > #you have to say just what a machine is... the C abstract machine > #one has to program only one machine > #or the one machine is a subMachine of the machine > #and not a set of machines or cpus well as long as all implementatons obey the semantics of the C abstract machine we don't have a problem. In a sense this is what Rod Pemberton is doing; he's inspecting each implementation to ensure it complies with the C abstract machine semantics. > #but > #if all cpu have register of 32 bits with usual 32 bit > #jump operation on code > #it would be possible programm all these cpu in the subcpu > #of 32 bit as it is one portable cpu, as just one machine seems way to low level to me. Who cares if its a 32 bit machien or a 19 bit machine? You do know there are 64 bit machines around now? and again "32 bit" gives way to much leeway for your sort of verifiction. What if its a 32 ARM? <snip>
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2012-02-20 17:36 -0500 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <jhuhvb$6sr$1@speranza.aioe.org> |
| In reply to | #14318 |
"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message news:2bc2a617-e283-44c7-9fd3-63d2887b896e@y10g2000vbn.googlegroups.com... > On Feb 20, 9:14 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> > wrote: ... > > [a Clike language] most likely inherited the basic > > functionality that a programmer needs to know. > > exceptions, closures, continuations, modads, > > lost of stuff C doesn't provide. Don't you mean: lots of stuff C doesn't need? ... How many of the languages which have a language feature that is "missing" from C are compiled to C or once were? (The great majority of them do or did. That includes C++ at one point in time via Cfront. Nearly all modern dynamicly typed languages do.) > > How do you know your compiler is compliant with a specification, > > or your compiler accurately implements what you expect your code > > to do? Testing only? What if you missed something you could've > > caught had you simply just read the assembly? > > in my experience compiler bugs are very rare Well, you must not have much experience. Or, you've just never noticed the errors because 1) you've never studied or verified the assembly output and 2) the error was never "triggered". I've found either compilation errors or library coding errors with most of the C compilers I've used. One compiler optimized away code that shouldn't have been, but only for one intermediate optimization level. All optimization levels above or below the intermediate level worked correctly. Another had type conversion errors in the assembly when a specific type was used with any other type. In one library, an erroneously coded function was supposed to return three states, but returned only two. Issues like these were not found in compilers where you'd expect them, say SmallC, but in quality compilers, like GNU C, OpenWatcom, etc. The problem with not looking at the assembly is that errors can exist for exceptionally long time periods before being noticed. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Mike McCarty <mcmccarty@gmail.com> |
|---|---|
| Date | 2012-02-20 15:27 -0800 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <21967632.3616.1329780456157.JavaMail.geo-discussion-forums@pbvr2> |
| In reply to | #14339 |
On Monday, February 20, 2012 4:36:39 PM UTC-6, Rod Pemberton wrote: > "Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message > > exceptions, closures, continuations, modads, > > > > lost of stuff C doesn't provide. > > Don't you mean: lots of stuff C doesn't need? ... That's arguable but I think most C++ programmers would say "With C++ I no longer need C." - and they are correct and happy to be able to say it. > > (The great majority of them do or did. That includes C++ at one point in > time via Cfront. Nearly all modern dynamicly typed languages do.) Irrelevant. You could've written them all in assembler if you so desired. It means nothing regarding the utility of the language. > > in my experience compiler bugs are very rare > > Well, you must not have much experience. Or, you've just never noticed the > errors because 1) you've never studied or verified the assembly output and > 2) the error was never "triggered". I've found either compilation errors or > library coding errors with most of the C compilers I've used. One compiler > optimized away code that shouldn't have been, but only for one intermediate > optimization level. All optimization levels above or below the intermediate > level worked correctly. Another had type conversion errors in the assembly > when a specific type was used with any other type. In one library, an > erroneously coded function was supposed to return three states, but returned > only two. Issues like these were not found in compilers where you'd expect > them, say SmallC, but in quality compilers, like GNU C, OpenWatcom, etc. > The problem with not looking at the assembly is that errors can exist for > exceptionally long time periods before being noticed. This is all very likely true but... what's your point? That software is buggy? That proving your program is bug-free is hard/impossible? To hell with the buggy compiler, the OS is buggy. To hell with the OS, the device drivers are buggy. To hell with the device drivers, the hardware is buggy. At what level of abstraction are you going to stop in your futile effort to prove that your program will execute correctly? Earlier you stated: > What if you missed something you could've caught had you simply just read the assembly? What if you missed something because you wasted all of your time analyzing assembler? Which of these two scenarios do you suppose is more likely to happen? Every once in a while, a colleague of mine will make some comment about adding some needless syntactic sugar to some code "just in case the compiler screws it up". 99 times out of 100, I respond "Well, if the compiler screws this up, we have much bigger problems than just this little bit of code." You can't predict bugs. If you could, the bugs probably wouldn't exist in the first place.
[toc] | [prev] | [next] | [standalone]
| From | Dombo <dombo@disposable.invalid> |
|---|---|
| Date | 2012-02-21 00:45 +0100 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <4f42daff$0$14714$5fc3050@news.tiscali.nl> |
| In reply to | #14339 |
Op 20-Feb-12 23:36, Rod Pemberton schreef: > "Nick Keighley"<nick_keighley_nospam@hotmail.com> wrote in message > news:2bc2a617-e283-44c7-9fd3-63d2887b896e@y10g2000vbn.googlegroups.com... >> On Feb 20, 9:14 am, "Rod Pemberton"<do_not_h...@noavailemail.cmm> >> wrote: > ... > >>> [a Clike language] most likely inherited the basic >>> functionality that a programmer needs to know. >> >> exceptions, closures, continuations, modads, >> >> lost of stuff C doesn't provide. > > Don't you mean: lots of stuff C doesn't need? ... The language itself doesn't need anything, the programmer however might appreciate some language features which makes him/her more productive. But if you consider features not strictly necessary to make a programming language Turing complete as unnecessary, maybe BF is the language for you. > How many of the languages which have a language feature that is > "missing" from C are compiled to C or once were? Even though it might be possible to compile those languages to C, the language constructs may still be very alien to C programmers. And the code these language constructs generate would never be written by a sane C programmer, simply because it is not practical if you have write it yourself. > (The great majority of them do or did. That includes C++ at one point in > time via Cfront. Nearly all modern dynamicly typed languages do.) >>> How do you know your compiler is compliant with a specification, >>> or your compiler accurately implements what you expect your code >>> to do? Testing only? What if you missed something you could've >>> caught had you simply just read the assembly? >> >> in my experience compiler bugs are very rare > > Well, you must not have much experience. Or, you've just never noticed the > errors because 1) you've never studied or verified the assembly output and > 2) the error was never "triggered". I've found either compilation errors or > library coding errors with most of the C compilers I've used. One compiler > optimized away code that shouldn't have been, but only for one intermediate > optimization level. All optimization levels above or below the intermediate > level worked correctly. Another had type conversion errors in the assembly > when a specific type was used with any other type. In one library, an > erroneously coded function was supposed to return three states, but returned > only two. If things don't work as expected I suspect the code being fed into the compiler first, only as a last resort I inspect the assembly output of the compiler. In the past twenty years I have run into maybe 3 or 4 compiler bugs, and about the same number in the libraries that came with them (on mainstream compilers, the statistics are a lot worse for some oddball compilers). I consider that rare, especially compared to most other software products. Now I'm sure that there are more bug in the compiler than I have been bitten by, but inspecting every assembly instruction generated by the compiler just isn't practical for software products where the HLL code consists of several million lines. > Issues like these were not found in compilers where you'd expect > them, say SmallC, but in quality compilers, like GNU C, OpenWatcom, etc. > The problem with not looking at the assembly is that errors can exist for > exceptionally long time periods before being noticed. Even if you analyze the assembly output, you still don't know if the code executes as intended. Many processors have lots of erratas and execute some instructions incorrectly in some corner cases. You might want to consider analyzing the processor design itself, just to be sure.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2012-02-21 04:35 -0500 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <jhvojb$vch$1@speranza.aioe.org> |
| In reply to | #14343 |
"Dombo" <dombo@disposable.invalid> wrote in message news:4f42daff$0$14714$5fc3050@news.tiscali.nl... ... > The [C] language itself doesn't need anything, the > programmer however might appreciate some language > features which makes him/her more productive. > C is very feature rich. You can do 97% of what needs to be done with C with just the C language and stdio.h, if you exclude a handful of functions that were placed in the 'wrong' include files. If you don't like extra coding you can use string.h. There is no need for ctype.h whatsoever. The remainder of the C library adds more "productive enhancing" code than your heart could ever desire ... If you took a language completely devoid of features, like BF which you've cited, then perhaps you have an argument. > But if you consider features not strictly necessary to make a > programming language Turing complete as unnecessary, maybe > BF is the language for you. 1) My understanding is that no programming language can be implemented as Turing complete due to architecture constraints such as fixed size integers and limited memory. 2) BF is novel, but it is currently too simple to program with effectiveness. One of the serious issues it has is it's minimalism. Various attempts have been made to enhance BF, such as PBrain and Toadskin. Procedures is one of the most common thing added to the language. PBrain adds that functionality but uses integers to represent the procedure. This complicates the use of the procedures. It also complicates the conversion of BF with PBrain procedures to other languages like C, since a cell may have a changing value, therefore call different procedures at different times. Toadskin adds the ability to group operators into named sequences, which is procedure like and Forth-like. IMO, BF's serious problem is that it is lacking direct, basic support for integers and characters as ASCII. Values must be constructed from increment or decrement loops. I've not seen variants of BF add the capability to express integers or characters directly. That ability combined with the ability to do procedures would make it roughly as powerful as a simple C compiler of yesteryear. You can check out Esolangs for more info on such languages: http://esolangs.org/wiki/Main_Page > > How many of the languages which have a language feature that is > > "missing" from C are compiled to C or once were? > > Even though it might be possible to compile those languages to C, the > language constructs may still be very alien to C programmers. And the > code these language constructs generate would never be written by a sane > C programmer, simply because it is not practical if you have write it > yourself. I would disagree with both claims. One could claim that being able to do so depends on skill level and work ethic. No skill? Lazy? > If things don't work as expected I suspect the code being fed into the > compiler first, only as a last resort I inspect the assembly output of > the compiler. Ah, but you do check assembly, in contrast to NK's claim that that is laughable. > In the past twenty years I have run into maybe 3 or 4 > compiler bugs, and about the same number in the libraries that came with > them (on mainstream compilers, the statistics are a lot worse for some > oddball compilers). Again, you've confirm my experiences in contrast to NK's claims. > Even if you analyze the assembly output, you still don't know if the > code executes as intended. Exactly. You won't know the code executes as intended until it is executed, which was why I asked this of NK: RP> How do you confirm correctness of both high-level and RP> low-level code with an imaginary machine? Is your RP> confirmation of correctness imaginary also? ... To which, I got more than one absurd response that imaginary confirmation of correctness was entirely valid ... Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-02-21 08:48 -0800 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <54f1f977-d567-4001-b9b8-fa954b93e7a2@s7g2000vby.googlegroups.com> |
| In reply to | #14358 |
On Feb 21, 9:35 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> wrote: > "Dombo" <do...@disposable.invalid> wrote in message <snip> > > In the past twenty years I have run into maybe 3 or 4 > > compiler bugs, and about the same number in the libraries that came with > > them (on mainstream compilers, the statistics are a lot worse for some > > oddball compilers). > > Again, you've confirm my experiences in contrast to NK's claims. 3 or 4 in 20 years sounds about right to me (a little high). Sounds pretty low to me. NK claimed bugs in compilers were pretty unusual. Sounds like we agree. > > Even if you analyze the assembly output, you still don't know if the > > code executes as intended. > > Exactly. You won't know the code executes as intended until it is executed, you can have a pretty good idea. And saring at megabytes of assembler ain't gonna help you. > which was why I asked this of NK: > > RP> How do you confirm correctness of both high-level and > RP> low-level code with an imaginary machine? Is your > RP> confirmation of correctness imaginary also? ... oh were you asking if I did unit tests? Yes various validations are done ***on the HLL code***. Including inspection, unit test and system test. Whats that got to do with asesmbly code? > To which, I got more than one absurd response that imaginary > confirmation of correctness was entirely valid ... have you heard of DbC or code inspection?
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-02-22 00:12 -0800 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <2748ae42-096c-429a-b517-e61681d0acd5@m2g2000vbc.googlegroups.com> |
| In reply to | #14386 |
On Feb 21, 4:48 pm, Nick Keighley <nick_keighley_nos...@hotmail.com> wrote: > On Feb 21, 9:35 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> > wrote: > > "Dombo" <do...@disposable.invalid> wrote in message > > > In the past twenty years I have run into maybe 3 or 4 > > > compiler bugs, and about the same number in the libraries that came with > > > them (on mainstream compilers, the statistics are a lot worse for some > > > oddball compilers). > > > Again, you've confirm my experiences in contrast to NK's claims. > > 3 or 4 in 20 years sounds about right to me (a little high). Sounds > pretty low to me. say 2 in 20 years taht's 1 every 10 years. So I didn't find them all myself, people I worked with did. Say the average team size is 5 that's 1 every 50 man years. So a programmer working alone would be lucky to see one compiler bug in his entire carreer. I call that rare. <snip>
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2012-02-22 06:12 -0500 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <ji2ijj$bal$1@speranza.aioe.org> |
| In reply to | #14386 |
"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message news:54f1f977-d567-4001-b9b8-fa954b93e7a2@s7g2000vby.googlegroups.com... > On Feb 21, 9:35 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> > wrote: > > "Dombo" <do...@disposable.invalid> wrote in message <snip> > > > In the past twenty years I have run into maybe 3 or 4 > > > compiler bugs, and about the same number in the libraries > > > that came with them (on mainstream compilers, the > > > statistics are a lot worse for some oddball compilers). > > > Again, you've confirm my experiences in contrast to NK's claims. > > 3 or 4 in 20 years sounds about right to me (a little high). Sounds > pretty low to me. The problem is they are a source of error you haven't located, but should. > NK claimed bugs in compilers were pretty unusual. > Sounds like we agree. Yes, I'd agree that you can agree with yourself and reference yourself in the third person too ... > > > Even if you analyze the assembly output, you still don't know > > > if the code executes as intended. > > > Exactly. You won't know the code executes as intended > > until it is executed, > > you can have a pretty good idea. Since when is "a pretty good idea" equivalent to confirming correctness of execution? > And saring at megabytes of assembler > ain't gonna help you. Do you stare at megabytes of HLL code too? That won't help you either ... > > which was why I asked this of NK: > > > RP> How do you confirm correctness of both high-level and > > RP> low-level code with an imaginary machine? Is your > > RP> confirmation of correctness imaginary also? ... > > oh were you asking if I did unit tests? Yes various validations are > done ***on the HLL code***. Including inspection, unit test and > system test. Whats that got to do with asesmbly code? Is the code executed as part of these tests? I.e., confirmed, but not confirmed on an "imaginary machine" ... (PS. Are you aware two letters in your various words have their locations switched? It's been quite a few times now ... asesmbly vs. assembly ... -ign vs. -ing ... etc) > > To which, I got more than one absurd response that > > imaginary confirmation of correctness was entirely valid ... > > have you heard of DbC or code inspection? By DbC, you mean like MISRA C, Safer C, or static code analysis, dynamic code analysis ... or something else? Wikipedia's DbC page mentions preconditions. I'd say that was the over 500 identical cut-n-pasted if() statements to determine if our data was in the correct location of the 5Mloc program I once worked on ... No we couldn't procedurize that if(). That would've been too slow, supposedly. Wait ... what?!?! So, you 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 ... Are you playing Devil's advocate? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-02-22 04:30 -0800 |
| Subject | Re: Learning to code by reading code |
| Message-ID | <3f734b2b-2d8a-4c73-81e3-3c43e39e16f7@y10g2000vbn.googlegroups.com> |
| In reply to | #14413 |
On Feb 22, 11:12 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> wrote: > "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message > news:54f1f977-d567-4001-b9b8-fa954b93e7a2@s7g2000vby.googlegroups.com.. > > On Feb 21, 9:35 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> > > > "Dombo" <do...@disposable.invalid> wrote in message > > > > In the past twenty years I have run into maybe 3 or 4 > > > > compiler bugs, and about the same number in the libraries > > > > that came with them (on mainstream compilers, the > > > > statistics are a lot worse for some oddball compilers). > > > > Again, you've confirm my experiences in contrast to NK's claims. > > > 3 or 4 in 20 years sounds about right to me (a little high). Sounds > > pretty low to me. [...] > > NK claimed bugs in compilers were pretty unusual. > > Sounds like we agree. > > Yes, I'd agree that you can agree with yourself and reference yourself in > the third person too ... I claimed compiler bugs were pretty rare. Someone came up with a number (3 to 4 cases in 20 years). You said "you've confirm my experiences". I pointed out that 3-4/20 years is a low rate and hence that compiler bugs /are/ pretty unusual. So we agree compiler bugs are fairly unusual? Note I'm fairly careful about what I say. When I say "fairly unusual" I don't mean "never happens". <snip> > > And [staring] at megabytes of assembler ain't gonna help you. > > Do you stare at megabytes of HLL code too? That won't help you either ... so what's the point of looking at the generated code? If the HLL verifies then the machine code has been verified as a side effect. > > > which was why I asked this of NK: > > > > RP> How do you confirm correctness of both high-level and > > > RP> low-level code with an imaginary machine? Is your > > > RP> confirmation of correctness imaginary also? ... > > > oh were you asking if I did unit tests? Yes various validations are > > done ***on the HLL code***. Including inspection, unit test and > > system test. Whats that got to do with asesmbly 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. What do you think a unit test is? And I'll point out again you misquoted me on "imaginary machines". Stop doing this. > (PS. Are you aware two letters in your various words have their locations > switched? It's been quite a few times now ... asesmbly vs. assembly > ... -ign vs. -ing ... etc) yes I'm a rubbish typeist > > > To which, I got more than one absurd response that > > > imaginary confirmation of correctness was entirely valid ... > > > have you heard of DbC or code inspection? > > By DbC, you mean like MISRA C, Safer C, or static code analysis, dynamic > code analysis ... or something else? Design by Contract > Wikipedia's DbC page mentions preconditions. and post-conditions? > I'd say that was the over 500 > identical cut-n-pasted if() statements to determine if our data was in the > correct location of the 5Mloc program I once worked on ... No we couldn't > procedurize that if(). That would've been too slow, supposedly. no idea what this has to do with DbC > Wait ... what?!?! So, you 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 ... Are you playing Devil's advocate? 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.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web