Good Books to learn low-level C

R

Ramzy Darwish

Hello,
I have a Bachelors in CS and a Masters in Comp. Graphics. In all of my
schoolwork, I used C and C++ and thought that I had a pretty good
understanding of the language(s). But now, as I really am trying to find
work as a C/C++ programmer, I am having trouble on programming interview
tests when they start asking about low-level C stuff dealing with memory and
binary numbers. Recently, I took a test for a SE position at Intel, which I
of course was very excited about, but I am pretty sure I bombed the test as
I didn't really know a lot of what they were asking and staying up all night
scouring the internet did not produce satisfying results (i.e. I didn't get
the job). I was able to come up with answers, but I don't think they were
correct as they will not respond to me (not even to say I failed).

What I want to know is how all of you out there learned the tricks that I
see you propose to questions dealing with C on a binary number level, or
actually using facts about the memory address of some data stored in memory.

I just ordered "Computer Systems: A Programmer's Perspective" and
"Illustrating C".
Of course I have K&R and Stroustrup, but they don't really go into this type
of stuff in detail (and I didn't expect them to).

Do you just have to learn it along the way like a lot of the PERL tricks?
Are there any books that teach you this stuff? Websites? Any help is
appreciated.

Thanks,
ramzy
 
M

Mike Wahler

Ramzy Darwish said:
Hello,
I have a Bachelors in CS and a Masters in Comp. Graphics. [...]
I am having trouble [...]
with memory and binary numbers.

This I find beyond incredible. What instutition
issued you those degrees?


This isn't a question or issue about C anyway,
so it's not topical here. BTW google will find
you plenty of tutorials on number-bases, e.g.
binary. You might also want to peruse www.drmath.com

-Mike
 
R

Ramzy Darwish

Maybe I didn't explain myself very well. I understand binary numbers and how
to work with them, and I know how to work with memory in terms of allocating
and deallocating and taking care of memory leaks and all of that. What I was
referring to were the tricks I see people play with using bit patterns to
determine mathematical properties of numbers (i.e. 1 then all 0's equal
power of two, etc.).

I know all about bases and took my architecture courses. I was just looking
for a book that maybe helped one to try to look at a lower level than say
objects or structs or something similar.


Mike Wahler said:
Ramzy Darwish said:
Hello,
I have a Bachelors in CS and a Masters in Comp. Graphics. [...]
I am having trouble [...]
with memory and binary numbers.

This I find beyond incredible. What instutition
issued you those degrees?


This isn't a question or issue about C anyway,
so it's not topical here. BTW google will find
you plenty of tutorials on number-bases, e.g.
binary. You might also want to peruse www.drmath.com

-Mike
 
C

Chris Croughton

Maybe I didn't explain myself very well. I understand binary numbers and how
to work with them, and I know how to work with memory in terms of allocating
and deallocating and taking care of memory leaks and all of that. What I was
referring to were the tricks I see people play with using bit patterns to
determine mathematical properties of numbers (i.e. 1 then all 0's equal
power of two, etc.).

Well, 00010000... is a power of the base in any base, how did you not
know that? The most 'obscure' one I've come across is that

a & (a-1)

removes the bottommost set bit, and that does need some thought.
I know all about bases and took my architecture courses. I was just looking
for a book that maybe helped one to try to look at a lower level than say
objects or structs or something similar.

The operations are simple, if you already understand binary and "know
all about bases" (assuming 'bases' in the mathematical sense).

<< shift left (multiply by a power of 2 modulo 2^n) & and the numbers (intersection)
| or the numbers (union)
^ exclusive or the numbers (difference)
~ invert the bits

The rest is mathematics. Mostly arithmetic...

Chris C
 
J

Jason Curl

Ramzy said:
Maybe I didn't explain myself very well. I understand binary numbers and how
to work with them, and I know how to work with memory in terms of allocating
and deallocating and taking care of memory leaks and all of that. What I was
referring to were the tricks I see people play with using bit patterns to
determine mathematical properties of numbers (i.e. 1 then all 0's equal
power of two, etc.).

I know all about bases and took my architecture courses. I was just looking
for a book that maybe helped one to try to look at a lower level than say
objects or structs or something similar.
Do you have examples of the questions they asked? This makes it easier
for me to understand what you mean by "low-level" C, whether it's
pointer arithmetic, or bitshifting, or what ever else.

Cheers,
Jason.
 
J

Jonathan Bartlett

What I want to know is how all of you out there learned the tricks that I
see you propose to questions dealing with C on a binary number level, or
actually using facts about the memory address of some data stored in memory.

I actually wrote my book on assembly language with people like you in
mind. It's called Programming from the Ground Up and is available at
http://www.cafeshops.com/bartlettpublish.8640017 and it gently
introduces you to things such as stacks, activation records, system
calls, binary numbers, memory management, and linking. It uses assembly
so that you can get a taste of how the machine itself is working, but
its purpose is to help you in other programming languages besides assembly.

Jon
 
S

Stephen Sprunk

Ramzy Darwish said:
I have a Bachelors in CS and a Masters in Comp. Graphics. In all
of my schoolwork, I used C and C++ and thought that I had a
pretty good understanding of the language(s). But now, as I really
am trying to find work as a C/C++ programmer, I am having trouble
on programming interview tests when they start asking about low-
level C stuff dealing with memory and binary numbers. Recently, I
took a test for a SE position at Intel, which I of course was very
excited about, but I am pretty sure I bombed the test as I didn't
really know a lot of what they were asking and staying up all
night scouring the internet did not produce satisfying results (i.e. I
didn't get the job).

Since you were applying for a job at a processor vendor, I'll take a stab in
the dark and say many of the things they asked about may have been
implementation-specific things that you would not have learned in general C
classes. That you classify the questions as "low-level" stuff reinforces
that guess, but without some example questions it's hard to say.

For better or worse, implementation-specific details of how C works on a
particular architecture and OS are off-topic here.
Do you just have to learn it along the way like a lot of the PERL
tricks? Are there any books that teach you this stuff? Websites?

<OT>
IMHO, the best way to learn the sorts of things I _think_ you were asked is
to get comfortable with assembly on your platform so that you can study the
output from your favorite compiler, both with and without optimizations. In
the process you'll learn all sorts of implementation-specific and low-level
stuff that portable C code should never be dependent on, e.g. stack frames,
number representations, endianness, syscalls/API calls, etc.

Not that I think that's a good idea in general, but it's probably what a
processor vendor is looking for in an SE -- someone who can "help" their
customers write C code that's targeted specifically to one platform and can
thus abuse implementation-specific details to improve performance on their
own platform while killing portability to competitors' platforms. Or
perhaps write implementation-level code that could never be portable in the
first place, like an OS kernel or drivers.

That's not necessarily a bad thing as long as you _know_ you're writing
unportable code. The key is not doing it when you don't intend to.
</OT>

S
 
C

CBFalconer

Stephen said:
Since you were applying for a job at a processor vendor, I'll take
a stab in the dark and say many of the things they asked about may
have been implementation-specific things that you would not have
learned in general C classes. That you classify the questions as
"low-level" stuff reinforces that guess, but without some example
questions it's hard to say.

On the contrary, from where I stand it sounds as if the OPs
education was sadly lacking in fundamentals. Memory and binary
numbers are pretty fundamental. Something like memorizing the
addition and multiplication tables in grade 2.
 
J

John Smith

WHO CARES IF IT IS OFF TOPIC.

Arse



Stephen Sprunk said:
Since you were applying for a job at a processor vendor, I'll take a stab in
the dark and say many of the things they asked about may have been
implementation-specific things that you would not have learned in general C
classes. That you classify the questions as "low-level" stuff reinforces
that guess, but without some example questions it's hard to say.

For better or worse, implementation-specific details of how C works on a
particular architecture and OS are off-topic here.


<OT>
IMHO, the best way to learn the sorts of things I _think_ you were asked is
to get comfortable with assembly on your platform so that you can study the
output from your favorite compiler, both with and without optimizations. In
the process you'll learn all sorts of implementation-specific and low-level
stuff that portable C code should never be dependent on, e.g. stack frames,
number representations, endianness, syscalls/API calls, etc.

Not that I think that's a good idea in general, but it's probably what a
processor vendor is looking for in an SE -- someone who can "help" their
customers write C code that's targeted specifically to one platform and can
thus abuse implementation-specific details to improve performance on their
own platform while killing portability to competitors' platforms. Or
perhaps write implementation-level code that could never be portable in the
first place, like an OS kernel or drivers.

That's not necessarily a bad thing as long as you _know_ you're writing
unportable code. The key is not doing it when you don't intend to.
</OT>

S
 
R

Randy Howard

What I want to know is how all of you out there learned the tricks that I
see you propose to questions dealing with C on a binary number level, or
actually using facts about the memory address of some data stored in memory.

This is interesting, as people complain about the lack of such
training in current degree programs fairly often, especially over
in comp.programming. You see, there was a time when this sort of
thing was a REQUIREMENT to make it through your degree program,
at least in the decent technical programs, particular CS, EECS,
etc. Maximizing tuition income seems to be more of a priority
for universities today, based upon this sort of thing coming up
all too frequently.

Many people learn this stuff over time on their own, before, during,
and after such coursework by writing software. The experience,
provided you aren't spending all your time painting forms in a web
browser and calling that programming, is likely to expose you to this
stuff gradually over time.

Working in a group of more experienced programmers willing to
mentor you is also a good way to pick it up. It sounds like
what you need right now is a crash course to get you up to
speed for interviews.
I just ordered "Computer Systems: A Programmer's Perspective" and
"Illustrating C".
Of course I have K&R and Stroustrup, but they don't really go into this type
of stuff in detail (and I didn't expect them to).

If you want it all in one place, try googling for HAKMEM, or a
somewhat easier read, but perhaps more interesting overall with
similar content in book form called "Hacker's Delight" by Henry
Warren. The term "hacker" in the title does NOT refer to people
breaking into computer systems in silly Hollywood movies, but the
real meaning of the word hacker.
ref: http://www.catb.org/~esr/faqs/hacker-howto.html
Do you just have to learn it along the way like a lot of the PERL tricks?

If you think they're tricks, you may not be learning them, but just
memorizing. You'll find that won't get you very far in the real
world. Understanding them means you'll be able to start from
some you already know and derive a new one when needed to solve
a novel problem. There are not many useful preordained "checklists"
in real programming to fall back on as a crutch. You can't go down
to your local bookstore and buy Cliff Notes on writing file systems,
or laminated sheets explaining the intricacies of project design.
Are there any books that teach you this stuff? Websites? Any help is
appreciated.

Probably the best place to start is Hacker's Delight if you want a
book. If you want to test the waters a bit first, find a copy of
HAKMEM and look it over.
 
E

Eric Sosman

CBFalconer said:
[...] Memory and binary
numbers are pretty fundamental. Something like memorizing the
addition and multiplication tables in grade 2.

ITYM "grade 10" ...

(Somewhere I once saw a snippet of somebody's scheme
for naming the natural numbers in base two. All I can
recall is that the sequence began "one, twin," and that
eight may have been "twosand." Can anyone recall seeing
this piece of whimsy?)
 
C

CBFalconer

Eric said:
[...] Memory and binary
numbers are pretty fundamental. Something like memorizing the
addition and multiplication tables in grade 2.

ITYM "grade 10" ...

I hope you didn't have to wait for grade 10 to learn "7 x 8 = 56".
Although with the prevalence of calculators in grade school it
seems the kids never learn the fundamentals. One can amaze them by
adding a column of numbers in ones head.
 
G

Guillaume

Hi,

sort of funny that many questions here actually have to be answered
by "you're not asking the right question".
 
C

Chris Croughton

Eric said:
[...] Memory and binary
numbers are pretty fundamental. Something like memorizing the
addition and multiplication tables in grade 2.

ITYM "grade 10" ...

I hope you didn't have to wait for grade 10 to learn "7 x 8 = 56".

"There are 10 sorts of people -- those who understand binary and those
who don't..."
Although with the prevalence of calculators in grade school it
seems the kids never learn the fundamentals. One can amaze them by
adding a column of numbers in ones head.

I don't think I ever did learn 7 x 8 by memorising, by the time we got
to the 7 times table I'd worked out that

(a) 7 x 8 == 8 x 7
(b) 8 x 7 == 10 x 7 - 2 x 7

so 70 - 14 == 56 is easier. For me...

(I had no idea that the 'rules' I'd discovered had names like
commutative and associative, and no one had told me that the sequence 2,
4, 8, 16... was "powers of two", I'd just observed them empirically.
Having the 'tables' of additition and multiplication on the wall made
commutativity obvious, Lego bricks made associativity amost as
obvious...)

Chris C
 
E

Eric Sosman

CBFalconer said:
Eric said:
CBFalconer said:
[...] Memory and binary
numbers are pretty fundamental. Something like memorizing the
addition and multiplication tables in grade 2.

ITYM "grade 10" ...


I hope you didn't have to wait for grade 10 to learn "7 x 8 = 56".
Although with the prevalence of calculators in grade school it
seems the kids never learn the fundamentals. One can amaze them by
adding a column of numbers in ones head.

When I was in elementary school, I don't think we
learned multiplication and division until grade 11 or
perhaps 100. Algebra and rudimentary geometry showed
up by grades 111-1000, analytic geometry in grade 1010
(except they put me on an accelerated program so I did
the 1010 material in the summer after 1001 and started
trigonometry in 1010 instead of waiting until 1011).
Calculus wasn't until grade 1100.
 
R

Randy Howard

Eric said:
[...] Memory and binary
numbers are pretty fundamental. Something like memorizing the
addition and multiplication tables in grade 2.

ITYM "grade 10" ...

I hope you didn't have to wait for grade 10 to learn "7 x 8 = 56".
Although with the prevalence of calculators in grade school it
seems the kids never learn the fundamentals. One can amaze them by
adding a column of numbers in ones head.

Did you hear a loud whooshing sound as you posted that?

:)
 
C

CBFalconer

Eric said:
CBFalconer said:
Eric said:
CBFalconer wrote:

[...] Memory and binary
numbers are pretty fundamental. Something like memorizing the
addition and multiplication tables in grade 2.

ITYM "grade 10" ...

I hope you didn't have to wait for grade 10 to learn "7 x 8 = 56".
Although with the prevalence of calculators in grade school it
seems the kids never learn the fundamentals. One can amaze them by
adding a column of numbers in ones head.

When I was in elementary school, I don't think we
learned multiplication and division until grade 11 or
perhaps 100. Algebra and rudimentary geometry showed
up by grades 111-1000, analytic geometry in grade 1010
(except they put me on an accelerated program so I did
the 1010 material in the summer after 1001 and started
trigonometry in 1010 instead of waiting until 1011).
Calculus wasn't until grade 1100.

Oh very well. :) Every group has its troublemakers.
 
Z

Zephryn Xirdal

It's very dificult to find tech. lit. about that. Low level programming with
C is a very closed kind of work, and sometimes you've to fight with strange
non-standard C compilers made only for the processor in question.

You've to learn some (sometimes a lot) about hardware, that is phisical
signals like chip select, write enable, CAS, RAS, etc.

But at end, it's not quite different from normal programming in C. You have
to know the underlayer hardware, and study electrical schematic of the
board, and read a lot of datasheets about the hard implicated.

You can begin studying a simple processor and buy an evaluation board, like
INTEL 8051, or you can launch yourself and be a man and buy something like a
ColdFire eval board (motorola's med-high processor).
 
A

Abhinav

A book which comes to mind is
Expert C Programming (1 edition)
Author: Peter van der Linden
If you are in the US you can use campusi.com to find the cheapest
available copy. No I dont work for that website nor do I have that book
to sell.
 
Z

Zephryn Xirdal

Thx. I don't know that book.

Other thing to learn how to program hardware is understand the Linux kernel,
at least the most low level layer.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top