Lecture 6: Static Data and Memory Organization (by Trek Palmer)
==============================================

Static data
-----------
	Up to now, you've had to accept that things like .text and .data
were 'magical' tokens necessary to placate the assembler. .text signifies
the beginning of the text segment. Despite the unusual name, text simply
means code. So the text segment is where all your code is stored. .data
signifies the beginning of the data segment. Now the data segment doesn't
store all your data, only your static data. In Java, you haven't had to
really make a distinction between static and dynamic data. But, basically,
dynamic data is data whose size is unknown at compile time. Essentially
everything you had to use 'new' for in Java. Static data is everything
else, all the global data whose sizes you know ahead of time. Although, for
now, this distinction between static and dynamic data may seem a little
arbitrary, there are good reasons for the distinction and as we explore how
systems actually manage memory the reasons should become clearer.

	The syntax of elements in the data section is fairly standard:
<label>    <size specifier>   <constant value>
The label is not strictly required, but without one, accessing your static
data becomes tricky. The size specifier comes in three exciting flavors:
.int meaning that the constant is a 4-byte (32-bit) integer value, .ascii
meaning that the constant is a string of single byte ASCII characters, and
.byte meaning that the constant is a byte value (specified as either a
numeric constant or as a single character). 
Examples:

foo:     .int      #h1234ABCD
bar:     .byte     #hFF
baz:     .byte     'd'
gah:     .ascii    "This is a string in memory"

	The static data will be loaded into memory along with your code,
but because the ARM is a RISC machine, the values will not be directly
accessible to instructions. Because ARM instructions only deal with
registers, there are two special instructions to load values from memory
into a register, and store a value from a register into memory. These
instructions are named, conveniently enough, Load and Store.

Examples:
	LDR   R1, foo

	loads the word at label foo into R1.

	LDR   R1, [R4]

	loads the word at the address stored in R4 into R1

	LDR   R1, [R4, #16]

	loads the word at the address stored in R4 + 16 into R1

	LDRB  R1, [R5]

	loads the byte at the address stored in R5 into R1

	STR   R2, [R3]

	Stores the word in R2 at the address in R3

	STRB  R3, [R4, #4]

	Stores the byte in R3 to the address stored in R4 plus 4


Endianness
-----------
	As you may recall from previous lectures, memory is essentially a
gigantic byte array. Every byte in memory is independantly addressable, but
the ARM (and most processors besides) deal with values larger than a single
byte. Most machines can deal with individual data of 1, 2, 4, and sometimes
8 bytes in size. Now there's a further question, which is how do we layout
the 4 bytes in a 32-bit value in memory. There are several options, but
most architectures fall into two camps.

  31 ... 24 | 23 ... 16 | 15 ... 8 | 7 ... 0
  Byte 3    |  Byte 2   |  Byte 1  | Byte 0

	The little-endian camp lays out the bytes thus:

Memory Address: 0xYYYYYYY0 | 0xYYYYYYY1 | 0xYYYYYYY2 | 0xYYYYYYY3
Byte          :  0         |  1         |  2         |  3

	The big-endian camp lays out the bytes thus:

Memory Address: 0xYYYYYYY0 | 0xYYYYYYY1 | 0xYYYYYYY2 | 0xYYYYYYY3
Byte          :  3         |  2         |  1         |  0

	There really isn't any advantage to either scheme, but the way it's
panned out is that most architectures are big-endian (the ARM is), but
Intel's x86 systems are little endian. Big endian is really the standard,
though. Network data has been standardized to be big endian.

Examples:

Word1:  0xCAFEBABE
Bytes:  0xCA | 0xFE | 0xBA | 0xBE
big:    0xCA | 0xFE | 0xBA | 0xBE
little: 0xBE | 0xBA | 0xFE | 0xCA

Word2:  0x1234ABCD
Bytes:  0x12 | 0x34 | 0xAB | 0xCD
big:    0x12 | 0x34 | 0xAB | 0xCD
little: 0xCD | 0xAB | 0x34 | 0x12

	As you can see, big endian organization lays out the bytes in
memory similarly to the way we write them out by hand, and little endian
in the reverse order. Another way to remember the difference is that in
big-endian the MSB is the 0-th byte, but in little-endian the LSB is the
0-th byte.


Alignment
---------
	In the previous examples, the word values began on a address that
ended in a 0 (which is evenly divisible by 4). There's no particular reason
why this should be so, for instance the integer could be stored like this
in memory:

Memory Address: 0xYYYYYYY0 | 0xYYYYYYY1 | 0xYYYYYYY2 | 0xYYYYYYY3
Byte          :  ?         |  0         |  1         |  2
Address       : 0xYYYYYYY4 | 0xYYYYYYY5 | 0xYYYYYYY6 | 0xYYYYYYY7
Byte          :  3         |  ?         |  ?         |  ?

	And, in fact, on some architectures (like the x86), this layout is
perfectly legal. But, due to the way memory is implemented it is actually
faster to access a four-byte value stored at an address divisible by 4
(4-byte aligned, we systems nerds like to say). Even on Intel boxes,
compilers try to make data aligned in order to speed up accesses. Many
architectures don't allow unaligned acesses and stores (ARM and SPARC). 
Some architectures permit them, but at substantial penalty (PowerPC).

	Basically there are 4 kinds of alignment: byte-alignment (that is,
no alignment at all), 2-byte or half alignment, 4-byte or word alignment,
8-byte or double-word alignment. The rolecks assembler by default does word
alignment, which means that for static data that doesn't end on a word
boundary, it'll pad it with zeros.

ASCII
------
in hexidecimal:

     00 nul   01 soh   02 stx   03 etx   04 eot   05 enq   06 ack   07 bel
     08 bs    09 ht    0a nl    0b vt    0c np    0d cr    0e so    0f si
     10 dle   11 dc1   12 dc2   13 dc3   14 dc4   15 nak   16 syn   17 etb
     18 can   19 em    1a sub   1b esc   1c fs    1d gs    1e rs    1f us
     20 sp    21  !    22  "    23  #    24  $    25  %    26  &    27  '
     28  (    29  )    2a  *    2b  +    2c  ,    2d  -    2e  .    2f  /
     30  0    31  1    32  2    33  3    34  4    35  5    36  6    37  7
     38  8    39  9    3a  :    3b  ;    3c  <    3d  =    3e  >    3f  ?
     40  @    41  A    42  B    43  C    44  D    45  E    46  F    47  G
     48  H    49  I    4a  J    4b  K    4c  L    4d  M    4e  N    4f  O
     50  P    51  Q    52  R    53  S    54  T    55  U    56  V    57  W
     58  X    59  Y    5a  Z    5b  [    5c  \    5d  ]    5e  ^    5f  _
     60  `    61  a    62  b    63  c    64  d    65  e    66  f    67  g
     68  h    69  i    6a  j    6b  k    6c  l    6d  m    6e  n    6f  o
     70  p    71  q    72  r    73  s    74  t    75  u    76  v    77  w
     78  x    79  y    7a  z    7b  {    7c  |    7d  }    7e  ~    7f del