Search

In the last chapter, we learned the basic structure of an assembly language program and how to assemble, link, and run it and display the exit status code. This chapter will focus on getting to know the register set of the x86-64 ISA as well as learning a few new instructions to make the code a little more interesting. We will start by looking at a few arithmetic instructions so we can expand beyond just moving data around.

In this chapter, we will discuss instructions which are not used quite as often, but are still important to know in order to be able to write and read assembly language code well.

The stack is an area of memory that is used to store values which will eventually be discarded.

So far, we have not gone into detail about what the memory layout of a Linux process looks like, primarily because we hadn’t covered enough material to make sense of it. In this chapter, we will look at how Linux processes work with memory and how to make your process request more memory from the operating system.

This book focuses on using ASCII codes for character data. As mentioned, the reason for this is that ASCII is fairly straightforward and is also compatible with the more advanced international standard, Unicode, to some degree.

So far, we have only considered values that are nonnegative integers. Technically, this is really what all values are underneath the covers. However, using special instructions and flags of the %eflags register, the CPU can treat these values as if they were different kinds of numbers (such as signed integers or even decimal numbers). In this chapter, we will look at these instructions and flags and aim to understand how the processor deals with these values.

This book has been focused on assembly language programming. For most computer programmers, assembly language is really the lowest-level language they will ever need to deal with. Nonetheless, for those interested in going deeper, here we will give a small taste of what is beneath.

The command line is one of the most useful tools for a programmer in the long run, but it is one that is tucked and hidden away from ordinary users. With the command line, instead of pointing and clicking to tell the computer what to do, you type commands that the computer reads and then runs. For the most part, each command is actually its own tiny (or not so tiny) program that does just one job for you. It is like a mini programming language that executes as you type each line.

We have talked enough about programming—it is time to actually get started! This chapter will start out with an extremely simple assembly language program just to show the basics of how to convert an assembly language program into a program you can execute. Then, we will move on and add some extremely basic functionality to our program. After that, we will have enough background knowledge to go into more depth about assembly language programming.

Nearly every programming language has some features to track memory allocations. Some, like the C programming language, are primitive. In Chapter 14, we learned how to implement basic procedures for allocating and deallocating memory for a program and managing the amount of memory we requested from the kernel.

The following commands are given by their instruction family name. For instance, movq, movl, etc. are simply referred to by their family name, mov. Since registers often need to be referred to in the description, we will refer to their 64-bit version, but if you are using a smaller version of the command, you will usually be using the smaller version of the register. For instance, on the mul command, the table describes its function as working with %rax, but mull would be working with %eax instead, and mulw would be working with %ax.

While registers store the values that the CPU is actively processing, most of a program’s data is in main memory, not in registers. In this chapter, we will learn the basics of how to access main memory in assembly language.

I’m going to now share with you the shocking truth about computers—computers are really, really stupid. Many people get enamored with these devices and start to believe things about computers that just aren’t true. They may see some amazing graphics, some fantastic data manipulation, and some outstanding artificial intelligence and assume that there is something amazing happening inside the computer. In truth, there is something amazing, but it isn’t the intelligence of the computer.

My goal for this book was to demystify what happens in computer programming. I think many people—even professional computer programmers—sometimes forget what is really happening under the hood. If you know assembly language, however, you can see how what you are doing in a high-level language is getting mapped onto the core constructs of assembly language. When a programming language implements a new feature, you can better understand both the feature itself and its possible limitations, because you can better imagine how it was implemented.

In Chapter 17, we discussed garbage collection. However, the code for the garbage collector was a little too long for inclusion in the chapter. This appendix has the complete code for the garbage collector.

This book has focused on the assembly language syntax used by the GNU Assembler, known as AT&T syntax, because it originated on Unix which was, at the time, developed by AT&T (the phone company). The reason for this is that it is the “native” syntax used in the Linux kernel and output by the GNU Compiler Collection. However, there is another syntax that is commonly used, which is known as “Nasm” Syntax (named after the popular assembler that uses it) or “Intel” syntax (because this is the syntax used in Intel’s manuals on their chips). If you want to learn new instructions from Intel’s manuals, you need to know Intel syntax, and this short guide should help you with most differences.

The goal of this part of the book is to demonstrate how features from higher-level programming languages map onto assembly language. Whether assembly language is your first programming language or your hundredth, its primary usage for the average programmer is to give them insight into what’s really happening under the hood of whatever language they are programming in.

Previous work suggests that there is an ordering to the discoverability of axioms, a "size" of sorts. However, there is not presently a method of measuring the size of an axiom. This paper suggests two possible methods for measuing axiom size. The goal is not to produce a definitive measurement technique, but to begin the exploration of different possible size measurements for axioms.

First year calculus is often taught in a way that is very burdensome to the student. Students have to memorize a diversity of processes for essentially performing the same task. However, many calculus processes can be simplified and streamlined so that fewer concepts can provide more flexibility and capability for first-year students., Comment: 13 pages

This letter provides a proof that Active Information and Generalized Information are both Specified Complexity models, and therefore the mathematics of Specified Complexity can be used to analyze them both.

In Chapter 12, we learned the basics of digital logic. However, I think we can all agree that those chips wound up taking up a lot of space on our breadboards. If we wanted to do a lot of complicated tasks, we would wind up needing a lot of chips, we would need more and more breadboards to put them on, and our project would get unwieldy very quickly. Additionally, as the number of chips increased, it would get very expensive to build such projects.

In the last two chapters, we have learned about the fundamental units of electricity—charge, current, voltage, and resistance. In this chapter, we are going to put this information to use in a real circuit.

In Chapter 18, we learned to make an oscillator circuit. Oscillations affect a lot of areas of electronics, but the one that is most directly usable (well, besides making blinky lights) is in making sounds.

In Chapter 5, we looked at our very first circuit and how to draw it using a circuit diagram. In this chapter, we are going to look at different ways components can be hooked together and what they mean for your circuit.

We will end our discussion of amplification by discussing partial circuits. Oftentimes you will need to design a circuit which connects to another circuit, either powering it or receiving power from it. For instance, in the amplification circuits from Chapter 25, the outputs were connected to a speaker. They could also be connected to another amplifier or to a stomp box (a device to modulate the incoming signal in some way) or a recording circuit.

In Chapter 24, we discussed two kinds of transistors—bipolar junction transistors (BJTs) and field effect transistors (FETs). The previous chapters have focused primarily on BJTs because they are, in fact, great at various tasks that are commonly considered “amplification.”

In Chapter 14, we learned how to do basic digital input and output with an Arduino using its I/O pins. In this chapter, we will cover how to do analog input and output as well.

In Chapter 11, we worked with our first integrated circuit, the LM393 voltage comparator. In this chapter, we are going to look at other ICs and talk more about how they are named and used in electronics.

Amplification is the conversion of a low-power signal to a higher-power signal. Normally when we think of amplification, we think of sound amplifiers for musical instruments. Indeed those are amplifiers, and we will build a sound amplifier later in this book. However, anytime you convert a low-power input to a higher-power output, you have amplified the signal, whether that was a DC signal or an AC signal. In this chapter, we will focus on amplifying DC signals.

So far, the components we have studied are simple, basic components—batteries, resistors, diodes, and so on. In this chapter, we are going to start to look at integrated circuits, also called chips, microchips, or ICs. An IC is a miniaturized circuit placed on silicon. It is a whole collection of parts geared around a specific function. These functions may be small, such as comparing voltages or amplifying voltages, or they may be complex, such as processing video or even complete computers. A single chip may hold just a few components, or it may hold billions.

In Chapter 5, we learned how a circuit works. However, the method of putting together a circuit in the chapter doesn’t translate to the real world well. In this chapter, we will learn how to use solderless breadboards to construct circuits in a more robust manner. Additionally, we will put our understanding of Ohm’s law to the test as we learn how to measure voltages in circuits using our multimeter.

In Chapter 17, we learned how to use RC (resistor-capacitor) circuits to create timers. In this chapter, we are going to use our concept of timing circuits to move from one-time timer circuits to oscillating circuits.

There is a little bit of confusion over what it is to “be in the cloud.” Some people even mistakenly think that just being on the Internet is utilizing cloud technology.

At this point, we have a simple cloud application which works on a single server. While it is nice that we can put this on a server that we built just by pointing and clicking, this doesn’t take full advantage of the cloud. One of the goals of the cloud is to create an application cluster—a set of servers that work together to solve the problem, where the computing power can be expanded and contracted as needed.

So far, any time we have wanted to push an update to our cloud, we have had to reimage all of our servers. That isn’t terrible, but neither is it the best option. If you imagine running a server farm with 20 different servers, do you really want to go and reimage them all every time you redeploy code? Probably not. If you want to install a server patch, do you want to go and reimage all your servers? Again, probably not.

For a truly scalable site, another aspect that is often needed is unlimited disk storage. Managing large-scale storage for servers is truly a difficult feat. Deciding on how much redundancy, how much accessibility, how many disks per server, and how to manage the disks to make sure you know ahead of time if a disk is failing is a tough task. Even for small-scale sites, managing files can be difficult.

This chapter is not meant to be a complete guide to cloud security, but merely to point you in the right direction. Security is more of a process and way of thinking than it is a series of steps, so this chapter will focus on how you need to think to protect your servers’ integrity and your data’s integrity.

This chapter will cover several adjustments to the basic two-tier architectures described in the previous chapter.

While most of this book has focused on hosting your application on Linode, since so much of the cloud hosting is based on AWS, I think it is worthwhile to look at some of the hosting options on AWS.

So far, the focus of our scalability efforts for our cloud application has been the serving of dynamic content (i.e., content pulled from database queries). However, for many sites, dynamic content is actually the smallest part of their system. In fact, on any web site, most of the requests are not even for your dynamic content, they are for your static content—your images, stylesheets, and JavaScript. Therefore, when looking at ways to scale your application in the cloud, it is important not to forget to also scale your static assets.

Now that you have experience with multiple cloud providers, I hope that you are realizing that the basic components of clouds don’t really change all that much from provider to provider. Each one may call something different, may have a little different process for setting something up, or may have a few additional abilities or limitations compared to someone else. However, at their core, the basics of IaaS cloud hosting are pretty similar from provider to provider.

In this chapter, we are going to be creating an extremely simple web application to use for demonstration purposes in subsequent chapters. The goal here is to get a full, end-to-end application up and running.

As with most cloud providers, setting up a cloud server on Linode is extremely simple. This chapter shows you the basic process to get something up and running, with screenshots.

Previous work has extended the algebraic manipulability of total differentials. Here, we explore alternate notations for partial differentials which will allow for their algebraic manipulability.

Missing values in covariates of regression models are a pervasive problem in empirical research. Popular approaches for analyzing partially observed datasets include complete case analysis (CCA), multiple imputation (MI), and inverse probability weighting (IPW). In the case of missing covariate values, these methods (as typically implemented) are valid under different missingness assumptions. In particular, CCA is valid under missing not at random (MNAR) mechanisms in which missingness in a covariate depends on the value of that covariate, but is conditionally independent of outcome. In this paper, we argue that in some settings such an assumption is more plausible than the missing at random assumption underpinning most implementations of MI and IPW. When the former assumption holds, although CCA gives consistent estimates, it does not make use of all observed information. We therefore propose an augmented CCA approach which makes the same conditional independence assumption for missingness as CCA, but which improves efficiency through specification of an additional model for the probability of missingness, given the fully observed variables. The new method is evaluated using simulations and illustrated through application to data on reported alcohol consumption and blood pressure from the US National Health and Nutrition Examination Survey, in which data are likely MNAR independent of outcome.

At the core of engineering is human problem-solving. Creating a cognitive model of the task of problem-solving is helpful for planning and organizing engineering tasks. One possibility rarely considered in modeling cognitive processes is the use of Turing Oracles. Copeland (1998) put forth the possibility that the mind could be viewed as an oracle machine, but he never applied that idea practically. Oracles enable the modeling of processes in the mind which are not computationally based. Using oracles resolves many of the surprising results of computational problem-solving which arise as a result of the Tractable Cognition Thesis and similar mechanistic models of the mind. However, as research into the use of Turing Oracles in problem-solving is new, there are many methodological issues.