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

Groups > comp.lang.misc > #937 > unrolled thread

Re: Learning to code by reading code (was: The way to read STL source code)

Back to article view | Back to comp.lang.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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 "BartC" <bc@freeuk.com> - 2012-02-19 22:34 +0000
          Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-20 12:22 +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 05:13 -0800
          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 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 "BartC" <bc@freeuk.com> - 2012-02-22 12:59 +0000
                        Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-23 07:03 -0500
                          Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-24 14:20 +0000
              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 Marco van de Voort <marcov@toad.stack.nl> - 2012-02-19 11:27 +0000

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

#1028 — 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]

#1029 — 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]

#1030 — 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]

#984 — 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]

#985 — 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]

#990 — 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]

#992 — 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]

#1009 — 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]

#987 — 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]

#991 — 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]

#994 — 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]

#1012 — 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]

#993 — Re: Learning to code by reading code

"Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message
news:jhvobn$ujr$1@speranza.aioe.org...
> "Juha Nieminen" <nospam@thanks.invalid> wrote in message

>> 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.

In the case of a scripting language, this is largely irrelevant.

If all the language does is invoke other programs, then there would be no
measureable difference between an interpreter, and a native code version.

It also depends on how the language is used; it might be 100 times slower
than native code, but if runtimes are small anyway, then there may not be
much advantage in taking only 1msec to do something instead of 100msec.

> 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

An interpreter may well be *implemented* in assembly language. Every
instruction that the interpreter deals with could be implemented by a
carefully hand-crafted and optimised block of assembly code! Sometimes
better than automatically compiled code.

 2) they can't optimize and
> compile code sequences which dramatically slows down loops and other
> control-flow.

Tell that to the guy who implemented the LuaJIT interpreter. Numeric
benchmarks are often faster than optimised C!

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

I used to find that anyway, even when not generated by a machine..

> 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.

C is pretty good, but it has to spend a lot of time recognising constructs
in the source code could be expressed directly in a higher level language 
and which can be executed directly (vector operations for example). It 
doesn't always manage to do that.

And if implementing something unusual, you can often write almost directly
from pseudo-code in a higher level language, but a quick, throwaway
implementation in C may well be slower; you need to spend time with C in
achieving what's already been done inside the interpreter.

-- 
Bartc 

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

#1011 — Re: Learning to code by reading code

"BartC" <bc@freeuk.com> wrote in message news:jhvtig$fam$1@dont-email.me...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message
> news:jhvobn$ujr$1@speranza.aioe.org...
...

> > 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
>
> An interpreter may well be *implemented* in assembly language.

That's typical.

> Every instruction that the interpreter deals with could be implemented
> by a carefully hand-crafted and optimised block of assembly code!

So?  An interpreter still reimplements for a virtual machine what native
assembly already does, i.e., slower.

> Sometimes better than automatically compiled code.

The "hand" optimized sequences for interpreters are much smaller than what a
compiler usually optimizes.  So, while the small pieces might be optimized
better, overall the larger compiler pieces are better optimized.

> >  2) they can't optimize and compile code sequences which
> > dramatically slows down loops and other control-flow.
>
> Tell that to the guy who implemented the LuaJIT interpreter. Numeric
> benchmarks are often faster than optimised C!
>

Well, tell him JIT is not an interpreter:
http://en.wikipedia.org/wiki/Just-in-time_compilation

> C is pretty good, but it has to spend a lot of time recognising constructs
> in the source code [which] could be expressed directly in a higher level
> language and which can be executed directly (vector operations for
> example). It doesn't always manage to do that.

Those constructs must still be converted to assembly.  So, even if you can
"express them directly", what real advantage is that?  They have to be
converted to the underlying assembly language no matter what.  If you're
looking for "short-hand" to express "missing" some constructs, use some
integers and an array ...

> And if implementing something unusual, you can often write almost directly
> from pseudo-code in a higher level language, but a quick, throwaway
> implementation in C may well be slower; you need to spend time with C in
> achieving what's already been done inside the interpreter.
...


Rod Pemberton

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

#1015 — Re: Learning to code by reading code

"Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message
news:ji2ht3$9j3$1@speranza.aioe.org...
> "BartC" <bc@freeuk.com> wrote in message
> news:jhvtig$fam$1@dont-email.me...
>> "Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message
>> news:jhvobn$ujr$1@speranza.aioe.org...
> ...
>
>> > 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

What does that mean?

>> An interpreter may well be *implemented* in assembly language.
>
> That's typical.

(Actually I don't think it is typical. C seems to be popular for such
things.)

>> Every instruction that the interpreter deals with could be implemented
>> by a carefully hand-crafted and optimised block of assembly code!
>
> So?  An interpreter still reimplements for a virtual machine what native
> assembly already does, i.e., slower.

I don't understand that either. But perhaps you're comparing an interpreter
and compiler for the *same* static language? My assumption is that
interpreters are used for dynamic languages, and compilers for static ones.

>> Sometimes better than automatically compiled code.
>
> The "hand" optimized sequences for interpreters are much smaller than what
> a
> compiler usually optimizes.  So, while the small pieces might be optimized
> better, overall the larger compiler pieces are better optimized.

That's true up to a point. But when interpreters are working with
higher-level data, you might need fewer pieces anyway; see my a:=b*c example
below. Also with a limited number of handlers for each bytecode, the entire
executable code can be more compact than that of equivalent compiled code
(even allowing for the extra data demands of the bytecode itself), making it
more cache-friendly.

>> >  2) they can't optimize and compile code sequences which
>> > dramatically slows down loops and other control-flow.
>>
>> Tell that to the guy who implemented the LuaJIT interpreter. Numeric
>> benchmarks are often faster than optimised C!
>
> Well, tell him JIT is not an interpreter:
> http://en.wikipedia.org/wiki/Just-in-time_compilation

LuaJIT, as I understand it, includes an interpreter, and is a drop-in
binary-compatible replacement for the standard interpreter. Some of the
performance is likely due to optimising those things which you complained
above that they can't do!

Your complaint then is that when an interpreter gets too clever, then it's
because it's cheating!

>> C is pretty good, but it has to spend a lot of time recognising
>> constructs
>> in the source code [which] could be expressed directly in a higher level
>> language and which can be executed directly (vector operations for
>> example). It doesn't always manage to do that.
>
> Those constructs must still be converted to assembly.  So, even if you can
> "express them directly", what real advantage is that?

Suppose you have a matrix as a built-in, intrinsic type. Then you can write:

a:=b*c

ie. matrix multiplication. Then the interpreter knows to invoke the fastest
possible code for the operation, already developed and optimised.

In something like C, this will be a mess of nested loops, array indices and
what-not which may or may not end up being compiled into the fastest
processor instructions.

-- 
Bartc 

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

#1020 — Re: Learning to code by reading code

"BartC" <bc@freeuk.com> wrote in message news:ji2otf$n6q$1@dont-email.me...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message
> news:ji2ht3$9j3$1@speranza.aioe.org...
> > "BartC" <bc@freeuk.com> wrote in message
> > news:jhvtig$fam$1@dont-email.me...
> >> "Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message
> >> news:jhvobn$ujr$1@speranza.aioe.org...
...

> >> > 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
>
> What does that mean?
>

It means that an assembly operation, say moving data to a register from
memory, will generally be one or maybe two instructions in assembly.
However, for a virtual machine used by an interpreter, there will be more
instructions to perform the equivalent move of data to a virtual machine
register from memory.  I.e., the use of a virtual machine forces the
hardware capabilities of a microprocessor to be reimplemented in software
for the virtual machine.  So, you've got say one or two instructions in
assembly for some operation, or you've got say five to ten instructions in
assembly to implement the same operation in assembly code for the virtual
machine.  The interpreter reimplements in assembly for it's virtual machine
what the instruction set already does for the native register set.  That's
overhead.

> >> Every instruction that the interpreter deals with could be implemented
> >> by a carefully hand-crafted and optimised block of assembly code!
> >
> > So?  An interpreter still reimplements for a virtual machine what native
> > assembly already does, i.e., slower.
>
> I don't understand that either. But perhaps you're comparing an
> interpreter and compiler for the *same* static language? My
> assumption is that interpreters are used for dynamic languages,
> and compilers for static ones.

It's true for any interpreter.

> >> Sometimes better than automatically compiled code.
> >
> > The "hand" optimized sequences for interpreters are much smaller than
> > what a compiler usually optimizes.  So, while the small pieces might be
> > optimized better, overall the larger compiler pieces are better
> > optimized.
>
> That's true up to a point. But when interpreters are working with
> higher-level data, you might need fewer pieces anyway; see my a:=b*c
> example below. Also with a limited number of handlers for each bytecode,
> the entire executable code can be more compact than that of equivalent
> compiled code (even allowing for the extra data demands of the bytecode
> itself), making it more cache-friendly.
>

With an interpreter, you have a bunch of small code snippets that have to be
executed.  If you call them, then the resulting code will not be as fast as
compiled code that will be inlined and not use calls.  Of course, there are
interpreters that can do inlining of code pieces, however, that requires a
built-in compiler which has overhead also.  With a compiler, the overhead is
in the compiler, it's not in the interpreter.  The resulting compiled code
from a compiler doesn't need an interpreter or built-in compiler.

> [...]
> Your complaint then is that when an interpreter gets too clever, then it's
> because it's cheating!

No, I just think the definition of an interpreter should be limited to
interpretation.  Compiling to compiling.  etc.  If it's some type of hybrid
system, of which there are a few, then we need another term(s) for it.
Some "interpreters" can generate inlined code.  They are hybrid combinations
of interpreting and compiling.

> >> C is pretty good, but it has to spend a lot of time recognising
> >> constructs in the source code [which] could be expressed
> >> directly in a higher level language and which can be executed
> >> directly (vector operations for example). It doesn't always
> >> manage to do that.
> >
> > Those constructs must still be converted to assembly.  So, even if
> > you can "express them directly", what real advantage is that?
>
> Suppose you have a matrix as a built-in, intrinsic type. Then you can
> write:
>
> a:=b*c
>
> ie. matrix multiplication.

Right, there is a slight advantage of not having to do a bit of programming
and convenient syntax ...  Where is the real advantage?  Matrix
multiplication is low use, at least for general programming.  Much of the
syntax complexity for another language like C can be hidden behind #define's
or procedures.

> Then the interpreter knows to invoke the fastest
> possible code for the operation, already developed and optimised.
>
> In something like C, this will be a mess of nested loops, array
> indices and what-not [...]

How is the interpreter any different than C here?  It too converts "a:=b*c"
into that "mess of nested loops [etc]" to perform the operation.  Some
interpreters could generate special microprocessor instructions or call a
handcoded routine for better performance, but that would be atypical ...
Also, it really defeats the purpose of an interpreter to put as much work
into it as a highly-optimized C library.  The purpose of an interpreter is
to be simple and interactive.

> In something like C, this will be a mess of nested loops, array indices
> and what-not which may or may not end up being compiled into the
> fastest processor instructions.

How is the interpreter any better here?  The interpreter must interpret a
large set of operations equivalent that "mess of nested loops" or it must
have a hand coded routine in assembly for speed ...  If the compiled code
doesn't need specialized instructions, then neither of those are likely to
be optimized better than the C compiler working on the "mess of nested
loops".  The only way handcoded assembly would be better is if specialized
instructions that the compiler can't generate are needed, i.e., the compiler
is producing code for the x86 and generates optimized GP instructions while
the handcoded routine is using faster MMX or SSE.  Most interpreters aren't
able to inline code pieces, so they must call each little routine which adds
overhead.  A compiler with optimization won't add that call overhead and can
optimize multiple pieces together.


Rod Pemberton

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

#1026 — Re: Learning to code by reading code

"Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message
news:ji5a0v$23m$1@speranza.aioe.org...
> "BartC" <bc@freeuk.com> wrote in message
> news:ji2otf$n6q$1@dont-email.me...

>> What does that mean?

> for the virtual machine.  So, you've got say one or two instructions in
> assembly for some operation, or you've got say five to ten instructions in
> assembly to implement the same operation in assembly code for the virtual
> machine.  The interpreter reimplements in assembly for it's virtual
> machine what the instruction set already does for the native register set.
> That's
> overhead.

No. You're assuming the interpreter is trying to do the same thing as the
compiled language/assembly language is trying to do.

But the interpreters I'm concerned with work at a slightly higher level than
that. The main problems are the usual overheads of interpretation
(dispatching to the next bytecode handler, type-dispatching (single or
double) to the proper handler for an arithmetic operation, etc).

To illustrate, take this example:

 A:=B+C

executed on an x86-32 machine. Assume that A,B,C are all of the same type.

With a statically compiled language, then when they are 32-bit integers, the
machine code might be 3 instructions. When 64-bits, then perhaps 6. When
64-bit floating point, then perhaps 3 again. But those were the easy ones!

But how many instructions would be generated when they are bigints? Or
extended precision reals? Or strings? Or arrays of ints? Or arrays of
vectors? How many instructions would be executed (as it is doubtful that
much would be done as inline code)?

An interpreter that uses dynamic typing might typically generate:

 push B
 push C
 add
 pop A

no matter how complex the types are. Even when the interpreter is told, or
caninfer, the types, there are still likely to be four bytecodes generated!
You can't really compare directly with how compiled languages work.

> With an interpreter, you have a bunch of small code snippets that have to
> be
> executed.  If you call them, then the resulting code will not be as fast
> as
 > compiled code that will be inlined and not use calls.

Actually my interpreter doesn't use calls (it uses jumps). And compiled code
is actually *more* likely to use calls, when the data it has to deal with is
more complex than a primitive type. Otherwise the inline code would be
sprawling.

> Right, there is a slight advantage of not having to do a bit of
> programming
> and convenient syntax ...

There are real, well-known advantages to using more productive/more
expressive languages, where you can concentrate on the task, rather than be
mired in the implementation details.

> Also, it really defeats the purpose of an interpreter to put as much work
> into it as a highly-optimized C library.  The purpose of an interpreter is
> to be simple and interactive.

(They can work together. It's quite typical to have an interpreter for
user-friendly language which provides an interface to that optimised C
library.)

>> In something like C, this will be a mess of nested loops, array indices
>> and what-not which may or may not end up being compiled into the
>> fastest processor instructions.
>

>  The only way handcoded assembly would be better is if specialized
> instructions that the compiler can't generate are needed, i.e., the
> compiler
> is producing code for the x86 and generates optimized GP instructions
> while
> the handcoded routine is using faster MMX or SSE.

OK, that's one way for an interpreter to conceivably be faster than C. But
I'm only arguing that they need not be as inefficient as you seem to think.

And when I first started using interpreted scripting languages for my
applications, a general rule I tried to keep to was that the performance
should be limited to being between one and two times as slow as compiled
code (not worse the half). So a bit slower, but development speed, 
maintenance, reliability, error-tolerance, readability and general 
productivity was far higher!

But the argument now is one of using the most productive language, rather
than interpreted vs. compiled where there is some overlap at the moment.

>  Most interpreters aren't
> able to inline code pieces, so they must call each little routine which
> adds
> overhead.  A compiler with optimization won't add that call overhead and
> can
> optimize multiple pieces together.

OK. Interpreters (many of which do have a source-to-bytecode compilation
phase), are not allowed to do optimisation. That'll keep them in their
place!

-- 
Bartc

 

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

#986 — Re: Learning to code by reading code

On Feb 20, 10:36 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Nick Keighley" <nick_keighley_nos...@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>

> > > [a C-like language] most likely inherited the basic
> > > functionality that a programmer needs to know.
>
> > exceptions, closures, continuations, monads,
>
> > lost of stuff C doesn't provide.
>
> Don't you mean: lots of stuff C doesn't need? ...

no. I'm saying there's lots of functionality a programmer might need
that is /not/ provided by C. Object oriented programming for a start.

> How many of the languages which have a language feature that is
> "missing" from C are compiled to C or once were?

many of them

> (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.)

so what? All HLLs are Turing equivalent. You can write Lisp
interpreters in Cobol if you wish to but I suspect it's painful.

Learnign other paradigms gives you more tools in your toolbox.

> > > 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.

fair enough

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

#980 — Re: Learning to code by reading code

Am 20.02.2012 10:14, schrieb Rod Pemberton:

> 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.

This is second-hand knowledge, but a co-worker of mine told me that
Analog Devices' "SHARC" DSP has 32-bit chars (i.e. CHAR_BIT==32). He had
lots of fun porting lwIP to it as you can't just overlay a struct on
some chunk of memory to parse the fields (like lwIP does)...


Peter

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

#1031 — Re: Learning to code by reading code

On Mon, 2012-02-20, Peter Remmers wrote:
> Am 20.02.2012 10:14, schrieb Rod Pemberton:
>
>> 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.

Like it or not, the people who defined C and C++ said it is not. So
the burden is on *us* who target mainstream platforms to document the
non-portable nature of our code (e.g. by using uint8_t if we need
8-bit unsigned calculations).

> This is second-hand knowledge, but a co-worker of mine told me that
> Analog Devices' "SHARC" DSP has 32-bit chars (i.e. CHAR_BIT==32).

I have first-hand knowledge of DSPs with 16-bit char and int.

> He had
> lots of fun porting lwIP to it as you can't just overlay a struct on
> some chunk of memory to parse the fields (like lwIP does)...

You can't do that on mainstream CPUs either, unless you manage the
alignment. (I'm sure someone will now argue that C should ignore
SPARC, ARM etc and hardwire itself to x86).

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

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

Back to top | Article view | comp.lang.misc

csiph-web