Lecture 7: Memory Organization and some I/O (by Trek Palmer)
==============================================

Memory Addressing modes, more formally
--------------------------------------

	Last lecture we saw several examples of LDR and STR instructions
that accessed memory directly, through a register, or through a register
with some extra computation. These different styles of accessing data are
collectively known as addressing modes.

	The table below lists the ARM's main addressing modes, their names, a
bit of example code and the address that would be generated by that example
instruction.

Addressing mode                     |  Example                 | Address Gen.
------------------------------------+--------------------------+---------------
Direct                              | LDR R0, <label>          | <label>
Register Indirect                   | LDR R0, [R1]             | R1
Reg. Indirect with Immed. Offset    | LDR R0, [R1, #-5]        | R1 - 5
Reg. Indirect with Reg. Offset      | LDR R0, [R1, R4]         | R1 + R4
Reg. Indirect with Scaled Reg. Offs | LDR R0, [R1, R4, LSL #4] | R1 + (R4 << 4)
------------------------------------+--------------------------+---------------

	The ARM also supports two additional options: pre-indexing and
post-indexing. When indexing, the base register is set to the generated
address and then the value is retrieved from memory.

	What's the point of all these addressing modes? Well direct and
register indirect may seem necessary (when retrieving a reference stored in
memory, such as in an object). But, how often does one need to use offsets
to justify the three additional addressing modes? There are two good
examples: the first is the old chestnut of arrays, the second is objects.

Array accesses
---------------
	Java has arrays, which are (particularly in the 1-D case) fairly
close to C arrays. For the most part, an array is just a big contiguous
chunk of memory. Arrays elements are all the same size, so if an array
element is k bytes large, an n-element array is k*n bytes large. So, to
access something in an array, you need two things. First, you need to know
where the array starts (the base of the array); and second, you need to
know at which index in the array the element you're interested in is (the
offset). In Java, the base is simply the reference that points to the
array, and the index is some integer you use the [] operator on. Consider
the following Java code:

	int[] foo = new int[10];

	int bar = foo[7];

	Assuming the address of foo is in R1, and bar in R2, is the following 
ARM code equivalent?

	LDR   R2, [R1, #7]

	No, it isn't. Because the size of a Java int is 4-bytes. This
instruction would actually cause an error because it would be doing a
mis-aligned read.

	How about this code?

	LDR   R2, [R1, #28]

	Or this?

	MOV   R3, #4
	MUL   R3, R3, #7
	LDR   R2, [R1, R3]

	Or this?

	MOV   R3, #7
	LDR   R2, [R1, R3, LSL #2]

	In fact, you now know enough assembly that you can rewrite the
whole Java program. So:

	int[] foo = new int[32];

        int bar = foo[7];

	Goes to:

	.text
	MOV   R1, foo
	MOV   R4, bar
	LDR   R2, [R1, #28]
	STR   R2, [R4]

	.data
foo:    .ascii  "This is a string of really only 40 chars"
bar:    .int    #0

	Given the preceding code, how would you implement the following
additional Java code?

	foo[3]++;
	foo[6] = foo[2] + foo[3] + bar;

	LDR  R5, [R1, #12]  ;getting foo[3]
	ADD  R5, R5, #1
	STR  R5, [R1, #12]
	LDR  R6, [R1, #8]   ; getting foo[2]
	ADD  R7, R6, R5     ; foo[2] + foo[3]
	ADD  R7, R7, R2     ; + bar
	STR  R7, [R1, #24]


Object field access
-------------------
	Classes are just, basically collections of data and some functions.
Objects are allocated all at once, so each of the fields starts at a
certain offset from the object base. Similarly to array accesses, getting
the value of an object field is just accessing something offset from the
object base. Unlike arrays, however, elements in an object can be different
sizes. This means it's harder to compile object accesses than array
accesses.

I/O
====
	Recall the old simple picture of a computer:

------------------------------------------------------
 ||              ||             ||              ||
 \/              \/             \/              \/
CPU            Memory          I/O             Secondary Storage
==========+   +===========+  +==============+  +==============+
-ALU      |   |-Just bytes|  |-keyboard     |  |-Disks        |
-Registers|   +===========+  |-mouse        |  |-Tape         |
-FPU      |                  |-display      |  |-Flash Media  |
-Control  |                  |-NIC          |  |-CD           |
==========+                  |-serial ports |  +==============+
                             +==============+

	The CPU has a dedicated connection to memory, but everything else
usually has to share a common bus. Accessing any of the bus-attached
devices is a process termed I/O (that stands for Input/Output).

	There are basically two methods for performing I/O that have
evolved: ports and memory-mapped I/O. With ports, there are special purpose
instructions to access I/O devices and read and write values from them.
With memory mapped I/O, the various memories and control registers of the
I/O devices are actually mapped to special memory addresses. So when you
read from one of these special addresses, the value is actually retrieved
from the device. No special instructions are needed, you can just use
memory instructions to manipulate I/O devices.

	The I/O devices are all hanging off of a single bus. Now, every bus
is different and has its own idiosyncrasies, but all busses have three main
components: address lines, data lines, and control lines.

	A generic view of an I/O device:

Address: --------------------------------------------------
Data   : ---^----------------------------------------------
Control: ---|------------------------------^---------------
            |             ^                |
	+---|-------------|----------------|-----------------+
        |   v             v                v                 |
        | +----------+  +-----------+  +------------------+  |
        | | Address  |  | Control   |  | Data,Control,and |  |
        | | Decoder  |  | Processor |  | Status Registers |  |
        | +----------+  +-----------+  +------------------+  |
        +----------------------------------------------------+

	The address decoder and control processor are for dealing with the
bus, and are, for the most part, transparent to the CPU. What we're
interested in are the Data and Control registers. These are registers or
special memories on the I/O device itself that allow us to control the
device, inspect its state, and read and write values from it. Although the
specific layout and meaning of these registers is fairly device dependent
there's some consistency. The status register(s) let you know what state
the device is in, the control register(s) accept coded values that cause
the device to do something, and the data register(s) store values just read
in, or to be written out.