What should every programmer know about internal devices?

What should every programmer know about internal devices? I do not mean hardware assembly or maintenance, but rather how the equipment actually works.

+6
hardware
source share
7 answers

You should know about:

  • Internal memory (ROM / RAM), differences with memory (HDD / DVD / CD). (Differences in speed and access method).
  • CPU / CORE'S what they do and what effects several cores have.
  • I / O, perhaps not so much, depends on the programming field.
  • Probably the address and data bus. What is the effect of the sizes of both.
  • Hardware interrupt, this hardware can interrupt the current program.
+7
source share

I would just recommend reading Programming from scratch :

This is an introductory book on programming and computer science using assembly language. He suggests that the reader has never programmed before, and introduces the concepts of variables, functions, and flow control. The reason for using assembly language is to make the reader think about how the computer actually works. Knowing how a computer works in terms of "pure metal" is often the difference between top-level programmers and programmers who can never master their art.

Old, but IMO remains relevant.

+5
source share

These computers speak binary. More specifically, understanding floating point representations. "Why does my math go wrong" is probably the most duplicated question about SO.

+4
source share

Endianness is an important concept to understand. Unintentionally mixing up your byte order can cause frequent painful debugs.

http://en.wikipedia.org/wiki/Endianness

+3
source share

It depends on the system you are developing with, when using smalltalk or lisp I would say no ^^ In python with a floating point everything will be fine. In C, I would say, finding out everything you can find ^^

0
source share

As computers get faster, some fundamental hardware aspects that have been consistent for decades have generally changed. While earlier it was possible to evaluate the performance of a code fragment by examining the resulting machine code and summing up the number of cycles required for various instructions, new processors with hyper-thread throw such calculations out of the window. In many cases, it is becoming increasingly important to consider compilers and processors as evil black boxes that will inspire the behavior of your code in all possible ways, which may still meet the language specifications. As a programmer who is very knowledgeable in hardware, this is disappointing. I can understand the need, but it belittles that most of my knowledge is becoming less useful.

0
source share

Say, for example, you were tasked with making a driver for some kind of robot. You will need to understand the insides of the robot. For example, a robot connects to a computer via usb. Then the driver will send it a command in the form of a packet. The robot interprets this command and begins to dance. Now tell me, they gave you this task, and now you have an idea about internal robots. You do not have a driver because you do not know how to program it. What is happening now is that you are at a loss, and you are stuck studying the insides of the robot because you thought you didn't need to learn the hardware. In general, this is not necessary for everyone, but it can help you in the long run.

0
source share

All Articles