Additional resources to understand C better.

Discussion in 'C Programming' started by Indian.croesus@gmail.com, Dec 16, 2006.

  1. Guest

    Hi,
    I apologise if this is not the forum for my question.

    I am a starter in C and I have come to a point where I can not figure
    out if knowledge of assembly language is really essential for an in
    depth understanding of C. Also while going through some of the old
    posts, essentially as an exercise to understand C better, I read the
    following from one Mr. Keith.

    "One concrete example is the C implementation on Cray vector machines.
    A machine-level address is a 64-bit quantity that points to a 64-bit
    machine word, but the C compiler has CHAR_BIT==8, so it needs a
    mechanism to point to 8-bit bytes within words. An int* pointer is a
    machine address, but a char* or void* pointer has a 3-bit offset
    stored in the otherwise unused high-order bits of a word pointer.
    This is implemented entirely in code generated by the compiler, not in
    hardware. A char* pointer value with a non-zero offset field is a C
    address, but it's not a machine address. "

    That just flew over the top of my head. :(

    What material, books or internet resources, can I read and / or code to
    understand that stuff.

    The problem with not knowing a thing and trying to learn is that one
    does not know how much one does not know. So if you can point me to
    additional material or topics that you feel one should know, please do
    point me to it.

    Thanks in advance.

    IC.
    , Dec 16, 2006
    #1
    1. Advertising

  2. Jack Klein Guest

    On 15 Dec 2006 20:26:18 -0800, ""
    <> wrote in comp.lang.c:

    > Hi,
    > I apologise if this is not the forum for my question.
    >
    > I am a starter in C and I have come to a point where I can not figure
    > out if knowledge of assembly language is really essential for an in
    > depth understanding of C. Also while going through some of the old
    > posts, essentially as an exercise to understand C better, I read the
    > following from one Mr. Keith.
    >
    > "One concrete example is the C implementation on Cray vector machines.
    > A machine-level address is a 64-bit quantity that points to a 64-bit
    > machine word, but the C compiler has CHAR_BIT==8, so it needs a
    > mechanism to point to 8-bit bytes within words. An int* pointer is a
    > machine address, but a char* or void* pointer has a 3-bit offset
    > stored in the otherwise unused high-order bits of a word pointer.
    > This is implemented entirely in code generated by the compiler, not in
    > hardware. A char* pointer value with a non-zero offset field is a C
    > address, but it's not a machine address. "
    >
    > That just flew over the top of my head. :(
    >
    > What material, books or internet resources, can I read and / or code to
    > understand that stuff.
    >
    > The problem with not knowing a thing and trying to learn is that one
    > does not know how much one does not know. So if you can point me to
    > additional material or topics that you feel one should know, please do
    > point me to it.
    >
    > Thanks in advance.


    These are the kind of thing that you _never_ need to worry about
    writing applications in standard C.

    Some programmers take advantage of the "fact" that certain types have
    the same size on the particular implementation they happen to be
    familiar code. The write code that unnecessarily makes use of this
    equivalence of size, then they are surprised when it breaks when
    compiler on a different platform, or maybe even a newer version of the
    same compiler.

    I assume the quotation was in reply to somebody who asserted that all
    pointers, or even all pointers to objects, have the same size. That
    is true in most C implementations, but not all.

    In the case Keith was talking about, the Cray is a computer that is
    built for sheer computation speed, what was then called a
    "supercomputer". It was not used for word processing or web browsing,
    but was a very, very expensive machine used for intense number
    crunching.

    To increase speed, it only reads and writes memory in 64-bit words.
    Period. All instructions operate on 64-bit integers or 64-bit
    floating point values.

    But even number crunching programs might need to write their results
    to text files that humans can read. To make it easier for programmers
    to use plain old ordinary text, the compiler and library implement an
    8-bit character type that is not supported by the hardware.

    If you want to have 8-bit character types on a computer that can't
    address quantities as small as 8 bits, you have two choices.

    Choice 1 is to use a whole 64-bit word for each character, storing the
    character in the lowest 8 bits and wasting the other 56 bits. But
    that can waste a lot of memory.

    Choice 2 is to pack up to eight of those 8-bit characters into each
    64-bit machine word. But the problem now is how to specify just one
    of those characters, when the hardware machine address is the address
    of the entire 64-bit word. To do that, you need a field of at least 3
    bits somewhere, that can hold eight different values specifying which
    of the eight characters in the machine word you want.

    So on this platform, a pointer to any of the character types, or a
    pointer to void, must have at least three additional bits of
    information that a pointer to a 64-bit double, for example, does not
    need.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
    Jack Klein, Dec 16, 2006
    #2
    1. Advertising

  3. goose Guest

    wrote:
    > Hi,
    > I apologise if this is not the forum for my question.
    >
    > I am a starter in C and I have come to a point where I can not figure
    > out if knowledge of assembly language is really essential for an in
    > depth understanding of C.


    Knowledge of assembly language is required for an in depth
    understanding of assembly language.

    It is possible (possibly not very useful) to have an in-depth knowledge
    of C and have absolutely no knowledge of the machine architecture
    you are targetting. Some might argue that this is the best way.

    The state you should be aiming for is absolute and in depth knowledge
    of C, while noting that many different architectures will implement the
    same thing differently (which is why learning by experimentation is
    not a Good Thing).

    > Also while going through some of the old
    > posts, essentially as an exercise to understand C better, I read the
    > following from one Mr. Keith.
    >
    > "One concrete example is the C implementation on Cray vector machines.
    > A machine-level address is a 64-bit quantity that points to a 64-bit
    > machine word, but the C compiler has CHAR_BIT==8, so it needs a
    > mechanism to point to 8-bit bytes within words. An int* pointer is a
    > machine address, but a char* or void* pointer has a 3-bit offset
    > stored in the otherwise unused high-order bits of a word pointer.
    > This is implemented entirely in code generated by the compiler, not in
    > hardware. A char* pointer value with a non-zero offset field is a C
    > address, but it's not a machine address. "
    >
    > That just flew over the top of my head. :(


    I wouldn't worry about it, if I were you. Mr Thompson and other
    regulars
    of this group tend to know all the arcane nooks and crannies of the
    C language *in addition* to knowing their target (and other)
    implementations
    thoroughly.

    Be careful not to mix up the two though. For example, if you experiment
    on your desktop and find that a long is exactly 32 bits wide, you
    cannot
    assume that a long in C is 32 bits wide always (a 64 bit platform might
    decide to have longs of 64 bits width).


    >
    > What material, books or internet resources, can I read and / or code to
    > understand that stuff.
    >


    Do you *want* to understand that stuff? The reason I ask is because
    that stuff will differ from platform to platform.

    > The problem with not knowing a thing and trying to learn is that one
    > does not know how much one does not know. So if you can point me to
    > additional material or topics that you feel one should know, please do
    > point me to it.
    >


    A good start would be the newsgroup for your particular platform.

    goose
    goose, Dec 16, 2006
    #3
  4. Randy Howard Guest

    goose wrote
    (in article
    <>):

    > It is possible (possibly not very useful) to have an in-depth knowledge
    > of C and have absolutely no knowledge of the machine architecture
    > you are targetting. Some might argue that this is the best way.


    Depends upon what you actually intend to do down the road, but
    in general, yes.

    > The state you should be aiming for is absolute and in depth knowledge
    > of C, while noting that many different architectures will implement the
    > same thing differently (which is why learning by experimentation is
    > not a Good Thing).


    It can be. For example, when you experiment with a single code
    base on multiple compilers, operating systems and processor
    architectures and see how they work the same or differ. It's
    "experimenting on a single system/compiler" that's prone to bad
    habit forming, imo.


    --
    Randy Howard (2reply remove FOOBAR)
    "The power of accurate observation is called cynicism by those
    who have not got it." - George Bernard Shaw
    Randy Howard, Dec 16, 2006
    #4
  5. Guest

    Thanks a lot all of you and thanks Mr. Jack, that really helped a lot.

    I am mighty confused. I think I understand C fairly well now and am
    comfortable with pointers but I do not know "what next". When I say
    that, I mean I am overwhelmed by the fact that I should learn about the
    calling conventions, as also concepts like implementing OOPS using C,
    or perhaps go through the C standards document, from cover to cover. So
    I need a little guidance in that direction. Perhaps I am not able to
    frame my question in a coherent manner but I am hoping that atleast
    some of you must have felt the same during your intial tryst with C and
    your experience can throw some light on how can I take the next step.

    Thanks once again.

    IC
    , Dec 16, 2006
    #5
  6. goose Guest

    Randy Howard wrote:
    > goose wrote
    > (in article
    > <>):
    >
    > > It is possible (possibly not very useful) to have an in-depth knowledge
    > > of C and have absolutely no knowledge of the machine architecture
    > > you are targetting. Some might argue that this is the best way.

    >
    > Depends upon what you actually intend to do down the road, but
    > in general, yes.
    >
    > > The state you should be aiming for is absolute and in depth knowledge
    > > of C, while noting that many different architectures will implement the
    > > same thing differently (which is why learning by experimentation is
    > > not a Good Thing).

    >
    > It can be. For example, when you experiment with a single code
    > base on multiple compilers, operating systems and processor
    > architectures and see how they work the same or differ.


    That's equally bad; what if all the ones you manage to get
    your hands on implement malloc using pages/blocks/whatever
    of 32 bytes?

    The learner gets the idea that malloc allocates in 32 byte blocks?
    The non-learner, OTOH, is presented with no danger in experimenting
    to determine what his implementation is doing in order to conform
    to the standard.

    Experimentation *while learning C* is a bad idea in general. I've seen
    too many students who believe that they "know" the number of bits
    in an int or that they "know" what happens when they go past the end of
    an array "in the C language" merely because they experimented and
    found out how all their implementations handle that particular UB.

    > It's
    > "experimenting on a single system/compiler" that's prone to bad
    > habit forming, imo.
    >


    Not only a single system, but many similar systems whose
    similarity is not obvious (different compilers for the same platform
    may produce the same opcodes for some C code while being
    different implementations).

    goose,
    goose, Dec 16, 2006
    #6
  7. Randy Howard Guest

    goose wrote
    (in article
    <>):

    >
    > Randy Howard wrote:
    >> goose wrote
    >> (in article
    >> <>):
    >>
    >>> It is possible (possibly not very useful) to have an in-depth knowledge
    >>> of C and have absolutely no knowledge of the machine architecture
    >>> you are targetting. Some might argue that this is the best way.

    >>
    >> Depends upon what you actually intend to do down the road, but
    >> in general, yes.
    >>
    >>> The state you should be aiming for is absolute and in depth knowledge
    >>> of C, while noting that many different architectures will implement the
    >>> same thing differently (which is why learning by experimentation is
    >>> not a Good Thing).

    >>
    >> It can be. For example, when you experiment with a single code
    >> base on multiple compilers, operating systems and processor
    >> architectures and see how they work the same or differ.

    >
    > That's equally bad; what if all the ones you manage to get
    > your hands on implement malloc using pages/blocks/whatever
    > of 32 bytes?


    A fair point, but certainly not the "what if" I had in mind.
    And also not without being informed, basically, that "all the
    world is not a VAX" before they get started. Or in more modern
    terms, x86. Add in endian issues, character sets, signed
    representations, etc. and pick good variety of targets to
    experiment on, and I contend it could have quite the opposite
    effect, for a suitably talented student. Given the proper
    briefing a good selection in platforms, anybody that still comes
    out with nothing but a bunch of misinformed assumptions form
    that isn't going to make it to the end of the runway anyway.

    > The learner gets the idea that malloc allocates in 32 byte blocks?


    Whoever said that experimentation must occur in isolation from
    other methods and teaching, like good instructors, or good text
    books and/or tutorials? You're trying to make a point about
    your opinion by carrying it to the point of absurdity through
    exaggeration. Sure, there are probably some folks that did
    /only/ what you describe without any other forms of learning to
    help correct any such bad ideas. I think they are vanishingly
    rare in the programmer population though. It was certainly more
    likely back when there so many fewer options when it came to
    learning materials as compared to today.

    > The non-learner, OTOH, is presented with no danger in experimenting
    > to determine what his implementation is doing in order to conform
    > to the standard.


    "The non-learner"? The "non-learner" doesn't learn anything at
    all. Do you mean the one that doesn't experiment with actual
    compilers, systems and architectures? IMO, you have to be
    incredibly uninterested in the topic as a whole to never go down
    that path, even a little bit, even when first getting past the
    few days with the language when it is explained that C lets you
    get closer to the bare metal than other HLLs.

    > Experimentation *while learning C* is a bad idea in general. I've seen
    > too many students who believe that they "know" the number of bits
    > in an int or that they "know" what happens when they go past the end of
    > an array "in the C language" merely because they experimented and
    > found out how all their implementations handle that particular UB.


    And I'll suspect that of those you have seen, very few of them
    experiments on a the kind of "variety" I had in mind when I
    wrote the above, or in total isolation from other forms of
    learning.


    --
    Randy Howard (2reply remove FOOBAR)
    "The power of accurate observation is called cynicism by those
    who have not got it." - George Bernard Shaw
    Randy Howard, Dec 16, 2006
    #7
  8. Chris Torek Guest

    In article <>
    <> wrote:
    >What material, books or internet resources, can I read and / or code to
    >understand that stuff.


    You do not *need* to know details about various machine architectures
    in order to use the C language. If you *want* to learn such things,
    though, your best bet may be a college course on hardware architectures.

    (It may also help to learn some background electrical-engineering
    principles, although even basic EE courses tend to be much more
    intensive than required for understanding simple digital logic.
    For instance, there is no need to know about Thevenin and Norton
    equivalents, much less analyzing AC circuits and transmission lines,
    in order to understand the basic workings of a D or J/K type
    flip-flop. Those two -- D and J/K -- are the basis for all other
    digital circuits. Of course, transmission line theory can help
    explain *why* a digital circuit is misbehaving, but that is another
    topic entirely. :) )

    Language courses (runtime organization of languages, compiler
    design, and so on) may also be helpful, and possibly operating
    systems courses.

    There are a lot of textbooks that would go with these (authored
    by folks such as Hennesy and Patterson, Silberschatz and/or Peterson,
    and so on). Knuth (all volumes) and Sedgewick are good reference
    works as well, although they focus more on algorithms and data
    structures.
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Dec 17, 2006
    #8
  9. <> wrote in message
    news:...
    > Thanks a lot all of you and thanks Mr. Jack, that really helped a lot.
    >
    > I am mighty confused. I think I understand C fairly well now and am
    > comfortable with pointers but I do not know "what next". When I say
    > that, I mean I am overwhelmed by the fact that I should learn about
    > the
    > calling conventions, as also concepts like implementing OOPS using C,
    > or perhaps go through the C standards document, from cover to cover.
    > So
    > I need a little guidance in that direction. Perhaps I am not able to
    > frame my question in a coherent manner but I am hoping that atleast
    > some of you must have felt the same during your intial tryst with C
    > and
    > your experience can throw some light on how can I take the next step.


    The first step is to start working with advanced data structures and
    algorithms, such as trees, hash tables, sorts, etc. You also need to
    learn how to decide which to use in various cases, and how to
    troubleshoot bugs. In fact, learning to use your debugger well is
    probably the single most important thing, since that's what you'll spend
    most of your time doing when you start writing more complex programs.
    Writing new code is a tiny, tiny part of most programmers' lives; the
    rest is spent fixing bugs or hacking in the occasional new feature.

    Another important step is learning what the Standard guarantees vs. what
    your implementation guarantees and/or what what you've found happens to
    work while experimenting. There are many things you'll have picked up
    assuming they're correct/portable (or not knowing there's a difference);
    porting a program from Windows to POSIX or vice versa is an eye-opening
    experience to folks who learned on a single platform. You'll find out a
    large part of what you "know" is simply wrong.

    That's not to say writing unportable code is bad -- but you need to know
    when that's what you're doing, and how to account for it, i.e. writing
    wrappers so that 90% of the code is portable and all you need to change
    when porting is to write a new wrapper. Networking, threads, GUIs,
    makefiles, etc. are all good things to learn once you've mastered the
    core language -- and learning how incredibly different they are on
    various OSes (if they exist at all) will teach you the importance of
    knowing what C guarantees vs. what an implementation
    provides/guarantees.

    After you've gotten past those hurdles, go find an open source project
    that intrigues you and simply read the code. Once you understand it
    (which, unless it's tiny, will take a while), try adding a new feature.
    It doesn't even matter how big it is or if anyone else finds it
    useful -- it's the process that you need to learn. Then go look up some
    bug reports and try to diagnose/fix one. If you succeed, contribute a
    patch.

    All that'll keep you busy for months or even years :)

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking


    --
    Posted via a free Usenet account from http://www.teranews.com
    Stephen Sprunk, Dec 17, 2006
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Russell E. Owen
    Replies:
    0
    Views:
    688
    Russell E. Owen
    Sep 8, 2006
  2. Roy Smith

    Trying to understand += better

    Roy Smith, Nov 23, 2009, in forum: Python
    Replies:
    8
    Views:
    304
    Terry Reedy
    Nov 30, 2009
  3. Zouplaz
    Replies:
    3
    Views:
    115
    Brian Candler
    Oct 11, 2008
  4. Frank Millman

    Trying to understand 'import' a bit better

    Frank Millman, Mar 4, 2012, in forum: Python
    Replies:
    0
    Views:
    107
    Frank Millman
    Mar 4, 2012
  5. davout
    Replies:
    5
    Views:
    74
    L D Jones
    Aug 6, 2004
Loading...

Share This Page