标签: assembly

One of our younger readers--we'll call Ryan (because that's his name)--is desperately keen to learn more about all aspects of electronics. Every now and then, an email will "ping" its way into my Inbox with a new question. The problem is that there's rarely an easy answer, because there are typically myriad underlying assumptions and potential areas for confusion.   Recently, Ryan has turned his attention to computers. Just a few minutes ago, for example, he sent me an email asking: "Can an operating system be created in assembly language? Also, what is the need for assembly in these days of languages like C/C++ and Java when memory is so cheap?"   Now, I must admit that I was tempted to send a short, quick, and easy (on me) answer, but I remember how confusing things were for me at the beginning -- plus I'm a bit obsessive-compulsive about this sort of thing -- so I responded as follows; I would be interested to hear your thoughts as to the way I presented all of this.   Hi Ryan -- as usual, there's more to your question than meets the eye LOL. Let's start with the fact that a processor (we'll focus on microprocessors/MPUs or microcontrollers/MCUs, but this applies to everything up to mainframe computers) ultimately executes what are called "machine code instructions." These are basically numbers representing instructions or data, where number 'x' might indicate an "Add" instruction, number 'y' might indicate a "Compare" instruction, and so forth. It is possible for someone to write a program directly in machine code -- but this is very laborious, time-consuming, and prone to error. It wasn't so bad in the very early days of computing when programs were really short and the computers themselves supported limited instruction sets and addressing modes, but it soon grew harder as computers increased in complexity. The next level up is to use assembly language, in which instructions are written using mnemonic names and you can declare labels and suchlike. In the really early days, you might write your program in assembly with pencil and paper and then hand-translate it into machine code. Later, you would use an assembler program to take your assembly source code and translate it into machine code. This actually provides a great example of "bootstrapping"; i.e., pulling oneself up by one's bootstraps. Here's the way it would go. You would define a very, very simple assembly language as a pencil-and-paper exercise. Then you would write a very rudimentary assembler in your assembly language -- again using a pencil and paper -- and you would hand-assemble this rudimentary assembler into machine code. This is where things get interesting. You would also write a very simple text editor (probably of a type known as ca "Line Editor") in your assembly language as a pencil-and-paper exercise, and you would hand-assemble this simple editor into machine code. Now you are in the position to capture simple programs in your assembly language using your text editor (in machine code) running on your computer, and then assembly them into machine code using the assembler program (in machine code) running on your computer. One of the first things you might do would be to use your simple editor to capture the source code for a slightly more sophisticated editor in your simple assembly language, and to then run this through your rudimentary assembler. Alternatively, you might capture the source code for a slightly more sophisticated assembler in your simple assembly language and run this through your rudimentary assembler. And so it would go, looping round and round using your existing editor and assembler to create bigger, better, easier-to-use versions with more functions and features. Now let's consider a modern language like C, for example. As you know, we use an editor program to create our source code in C, then we run this code through a compiler program, and -- ultimately -- we are presented with a machine code ("executable") equivalent. The first question we need to ask is: "Where did the compiler program come from?" In fact, if you were the person who created the compiler, then the first version (a very simple C compiler) would have been written in assembly language and run through your assembler program to generate the machine-code version of the compiler. This first version of your C compiler might only support a subset of the C language -- just enough to get you up-and-running. Once you had your first simple C compiler, you would probably hand-translate your original assembly code version of the compiler into your supported C subset equivalent, and then used your C compiler to compile its own source code in C and generate a new version of itself in machine code, just to make sure that everything was tickety-boo. After this, you would start to loop around creating new, more sophisticated versions of your C compiler, where each one was compiled into machine code using the previous version. Once again, you would be "pulling yourself up by your bootstraps." (For the purpose of our discussions thus far, we're assuming we go directly from assembly to C. In fact, there were other languages like FORTRAN in between, and it's more than likely that someone might have created a FORTRAN compiler in assembly, and then used FORTRAN to capture the first C compiler, but let's not wander off into the weeds.) Another interesting point is that, when someone creates a C compiler, they typically don't use it to generate machine code directly. Instead, the C compiler generates its output in assembly language source code, and then an assembler is used to take this source code and assemble it into machine code. All of this usually takes place "behind the scenes" or "under the hood," so most people don't even think about it, but expert users (including the compiler writers) often look at critical parts of the code generated in assembly language to see if they need to refine their C source code to better guide the compiler. Are we having fun yet (LOL)? OK, let's say we want to create a program that does something-or-other; perhaps it's a game of Breakout. We could create this program in assembly language or C. In the past, expert programmers would say that they knew lots of cunning tricks, so they could create smaller, faster programs in assembly language than could be generated using a C compiler. This was probably true, but it would have taken them a lot longer to do it; also, modern C compilers are very sophisticated and they typically know the same cunning tricks as the programmers. Be this as it may, we create our game in assembly or C, and then we assemble or compile it into a machine code (executable) equivalent. If we power-up the processor and point it as the first instruction of our program, then we say our program is running on the "bare metal" and we talk about this as "bare metal programming." This is still the way things are done for a lot of small embedded systems, like the microcontroller programs running on home thermostats, for example. But what happens if we want to quickly and easily switch between multiple programs. Or suppose we want to have multiple programs running at the same time (or, at least, appearing to run at the same time). Take your home computer, for example, you might have a web browser open and a Word document and an Excel document. In reality, the processor is time-slicing things -- it goes so fast that it can look at your mouse to see if you've moved it -- then switch to look at your keyboard to see if you've clicked a key -- then switch to one of the open programs to see if it needs to do anything -- then switch to the next program -- and so on and so forth. It does all of this so quickly that it appears to you, the user, that multiple things are happening simultaneously (let's keep things simple and assume a single processor/core and no multithreading). The point is that, in this case, we need to have a higher level program called an operating system (OS). We can think of the OS like the conductor of an orchestra, telling the horn section (one program) when to play and then telling the string section (another program) when to take over. And how is the OS created? Well, these little scamps come in all shapes and sizes. At one end of the spectrum we have incredibly large and complex monsters like Windows -- at the other end we might have something much, much simpler beavering away in a small embedded system. It's certainly possible to create a rudimentary OS in assembly language, but more-sophisticated systems would be created in C (or an equivalent high-level language). Returning to your original question, in the case of very low-level systems based on 8-bit microcontrollers, there are still quite a few older programmers who program exclusively in assembly language. There are also things like the PicoBlaze family of soft 8-bit processor cores used in Xilinx FPGAs that can only be programmed in assembly language because no one ever bothered creating a C compiler for them. When it comes to higher-level applications, some programmers may still hand-craft performance-critical functions in assembly language, but -- generally speaking -- this is becoming less and less common. Finally, for the moment, the underlying mechanisms behind languages like Python and Java are a whole different ball game involving things like "byte code" and "virtual machines," so I think we'll leave those for another day.   Good grief! Poor old Ryan. Even my head hurts now. This all seems so simple if you gloss over the underlying mechanisms and just say things like: "You capture your program in C and then use a compiler to translate it into an executable," but it becomes a lot more convoluted as you delve deeper into the morass.   On the other hand, I personally think this stuff is really interesting. I sometimes ponder what would happen if I were to stumble through a rift in time and space and I ended up having to develop a computer system (hardware and software) from the ground up. Hey, I'm sure we all worry about things like this... right? So, what do you think of my explanation above? Is this all "so-so soup" to you, or are there elements of this discussion that you never actually thought about before? Also, is there anything I misrepresented or missed out or that you think I should have covered in more detail?

When I first saw Richard Reese's Understanding and Using C Pointers , my reaction was "What! An entire book just about pointers?". It is actually a pretty good source of information about this critical subject. At times it is a bit repetitive; in other cases I think a more detailed explanation about an example would have been helpful. C pointers are a sore subject for a lot of people. Much C code is obviously written to avoid them; those developers probably don't have a deep understanding of the subject. Competent assembly programmers know that a pointer is akin to assembly's indirection and so they figure that the C version is no big deal. But in C they are far more nuanced than when working at the mnemonic level. The book is generally well-written and accurate, though a couple of flagrant mistakes were odd, like a comment that you can make a number negative by setting the MSB. Well, yeah, that will be negative but flipping the MSB will probably not yield the desired result. The subject is completely covered, and not just in isolation. For example, there's plenty about dynamic memory use, which is, of course, a place where pointers are required. The chapters give a good sense of the material: Introduction * Dynamic Memory Management in C * Pointers and Functions * Pointers and Arrays * Pointers and Strings * Pointers and Structures * Security Issues and the Improper Use of Pointers * Odds and Ends The chapter on security is of less interest than one might think. An experienced C developer will consider the issues identified as boneheaded mistakes. These include things like dangling pointers and the like. Perhaps a novice might find this information other than obvious. The last chapter talks about memory-mapped peripherals, aliasing, and threads, and has a very good description of callbacks. The author also goes into some OO concepts in detail, showing how to implement polymorphism in C. I'm not sure what the point(er) of that is; you might as well just use C++. Experts will get little to nothing from the book. Novices will learn a lot; much more than they will get about the subject in any other C book I have read. I'd highly recommend it for them after they learn the rudiments of the language. Those at the intermediate level will surely profit from reading Reese's book, probably more than they realise. The book cries out for a set of student exercises. It's easy to read a three line example and understand the principles. Until one tests one's knowledge by writing code and struggling to remember needed syntax the lessons won't be firmly implanted in the brain. What do you think? Are you proficient with using pointers?  

The environment during the assembly process is quite sensitive. Heat, humidity, and cleanliness should be strictly controlled. Depending on the product, a controlled clean room must be used to ensure cleanliness. For standard fine-pitch assembly and for consumer or non-critical business use, more standard conditions can be used. However, the cleanliness should exclude large contamination. Some dust might not matter, but large pieces of material can bridge conductors and cause problems. In this article I am going to spotlight two cleanliness issues, the first example shows an assembly area that does not have the expected cleanliness. The second illustrates an environmental issue that caused the product to fail. Figures 1 and 2 show the inside of a failing product. The product has a sealed enclosure, butÿthere are ants beneath the polyimide tape that was used as a protective layer as well as scattered on the PCB assembly (PCBA). You can only imagine the number of ants that must have been crawling around the assembly area to have two crawling on the PCBA surface so that they could be trapped with the small piece of tape. This manufacturing plant certainly needed an exterminator! Figure 1: Ant on the PCBA surface Figure 2: Ants beneath the polyimide tape. The second example comes from a product that failed in the field after two years of operation. This product was used in a janitorial closet (wardrobe?) in a school building. The outside environment was hot and humid, and it was located near a seacoast. Figures 3, 4 and 5 show some of the dust and debris found within the cabinet. Look at the number of mosquitoes (Figure 5) that had collected in the chassis over the two years! Figure 3: Dust and debris on memory ICs Figure 4: Dust and debris on headers. Header pins were also corroded Figure 5: Mosquitoes found in the chassis   In the second example, the product was thoroughly cleaned and tested. It was then fully operational, showing that it was the buildup of dust and debris that induced the failure. The dust and debris had absorbed enough humidity to become conductive. This conduction was enough to disrupt the signals to and from the memory devices. In this case, the corrective action was to install additional filtration to filter out some of the dust and to suggest that a janitorial closet was not the best place to house the equipment. What kind of gross contamination have you found in your products returned from the field? If you have some good PCB contamination photos, share them in the comments section with a brief explanation/caption. Michelle Woolley

Heat, humidity, and cleanliness should be strictly controlled during the assembly process. Depending on the product, a controlled clean room must be used to ensure cleanliness. For standard fine-pitch assembly and for consumer or non-critical business use, more standard conditions can be used. However, the cleanliness should exclude large contamination. Some dust might not matter, but large pieces of material can bridge conductors and cause problems. In this article I am going to spotlight two cleanliness issues, the first example shows an assembly area that does not have the expected cleanliness. The second illustrates an environmental issue that caused the product to fail. Figures 1 and 2 show the inside of a failing product. The product has a sealed enclosure, butÿthere are ants beneath the polyimide tape that was used as a protective layer as well as scattered on the PCB assembly (PCBA). You can only imagine the number of ants that must have been crawling around the assembly area to have two crawling on the PCBA surface so that they could be trapped with the small piece of tape. This manufacturing plant certainly needed an exterminator! Figure 1: Ant on the PCBA surface Figure 2: Ants beneath the polyimide tape. The second example comes from a product that failed in the field after two years of operation. This product was used in a janitorial closet (wardrobe?) in a school building. The outside environment was hot and humid, and it was located near a seacoast. Figures 3, 4 and 5 show some of the dust and debris found within the cabinet. Look at the number of mosquitoes (Figure 5) that had collected in the chassis over the two years! Figure 3: Dust and debris on memory ICs Figure 4: Dust and debris on headers. Header pins were also corroded Figure 5: Mosquitoes found in the chassis   In the second example, the product was thoroughly cleaned and tested. It was then fully operational, showing that it was the buildup of dust and debris that induced the failure. The dust and debris had absorbed enough humidity to become conductive. This conduction was enough to disrupt the signals to and from the memory devices. In this case, the corrective action was to install additional filtration to filter out some of the dust and to suggest that a janitorial closet was not the best place to house the equipment. What kind of gross contamination have you found in your products returned from the field? If you have some good PCB contamination photos, share them in the comments section with a brief explanation/caption. Michelle Woolley  

你可能会问，gcc不是用来在linux中编写C 语言代码的吗?是的，确实是这样，而我在这里其实就是在讲这件事情，不过有一点是不同的，我们首先能够写出C 语言的代码（如果不会，这篇文章对您或许是没有多大的用处的），而你也无需要很高超的编写C 语言的经验或是技巧，我们在这里需要的只是一些比较基本的代码，而且比起汇编的代码的编写来说（这里指的是汇编的初学者或是并不是很专业的编写者来说），编写C 的经历实在是比汇编要美妙多了，那么，这种美妙能否也用到汇编的编写上来呢？在这里，我给出我的答案，是的，可以。 之前我想要写一个汇编的浮点运算的代码，不过这个事情比较的麻烦，对于老到的程序员来说，这可能不是难事，而对于能够刚刚把无符号与有符号整数的加减法编写出来的人来说，浮点运算会显得有些不可思议，毕竟，按照我当时的理解，还是需要用寄存器，像是ax之类的，不过看来反复的实验下来这个问题不能得到有效的解决，首先是ax的规模对此是有很大的限制的，那么我们的运算很可能以失败告终，当然，这个难题不是难题，可以用内存来进行存取，这样的空间就肯定是足够的了的。 不过问题又来到了，小数，或是我们所遇到的浮点数，在内存中，或者说在运算的时候究竟是怎么样进行的？这当然需要去细细的探查浮点数的表示以及符号的处理方面的很多的规定，这又是一大段功夫。 然后就联想到，在windows中的VC编程工具里，有一个反汇编的功能，在linux中是否也有这样的一个功能呢?看来是有的，不然我也不会写出来，好的，废话就不多说，在linux中，gcc是个好东西，你可以在终端中调用她，虽然长得不好看，不是一个统一的集成的编译环境，不过就性能和功能而言，确实是不二的选择。 其实接下来的事情就很简单了，主要即使指令的使用，gcc -S这个命令就能完成你所需要的反汇编，这正是我们所需要的，用一种语言去学习另一种语言，在这里就是用C语言去学习汇编语言，去深入机器实现的内部，因为汇编是比C语言更为接近底层的语言，用C 语言写一段浮点运算的代码不是难事，接下来就是见证奇迹的时刻，用了以上的这个指令，你就能得到你所需要的汇编代码了，不过现在学得是8086的汇编，还是16位，而这里产生的肯定就是32位的运行的代码，在汇编代码，你几乎可以看到你所能看到的一切，硬件的一举一动都在你的掌控之中，好了，以后，通过这样的一条途径，我们的汇编学习之路就更加的好走了！