Array: Difference between revisions
m
→Indexing
Puppydrum64 (talk | contribs) m (→Assembly: formatting) |
Puppydrum64 (talk | contribs) m (→Indexing) |
||
Line 61:
myArray:
DC.B 10,11,12,13,14 ;typing the array in rows like this is only for the viewer's convenience - it means nothing to the CPU.
DC.B 20,21,22,23,24 ;all 25 entries could have been on one line in the same order and it wouldn't change how they are stored.
DC.B 30,31,32,33,34
DC.B 40,41,42,43,44
DC.B 50,51,52,53,54
Line 71:
It is <b>much</b> easier to work with arrays in assembly if all rows are the same length. The best way to deal with a ragged or jagged array, such as an array of strings of different lengths, is to store ''pointers to the array entries rather than the intended entries themselves.'' This equalizes the size of all the elements of the array which makes it much easier to index. Another way to handle such arrays is with padding, by adding extra null bytes to the ends until all rows are the same length, but for many data types it's better to construct an array of pointers.
In assembly, there is '''nothing''' stopping your program from indexing an array out of bounds! The computer doesn't have an understanding of where your array "ends," so asking it to return (for example) the 500th element of an array with only 25 elements is perfectly legal. This typically won't happen for arrays that aren't indexed based on user input, but be careful nonetheless. Indexing an array out of bounds and trying to read from it can cause segmentation faults on more modern machines, which is the operating system's way of preventing your code from reading memory that is outside of the program that is trying to index the array. Older CPUs don't have this sort of protection, and indexing out of bounds will read whatever is stored in memory at that location, which is why it falls into the realm of undefined behavior- the result entirely depends on how the code in your program is arranged.
====Iteration====
| |||