in a dangling pointer, makes P point to A, while puts the value of A into the location currently pointed to by P. In a similar fashion, SPL includes C-like array support in which the index variable is a number-of-words offset from the memory location set for the initial variable. Unlike C, SPL only provided one-dimensional arrays, and used parentheses as opposed to brackets. Variables could also be declared , in which case no local memory was set aside for them and the storage was assumed to be declared in another library. This mirrors the keyword in C. Literals can be specified with various suffixes, and those without a suffix are assumed to be . For instance, would be interpreted as an , while was a . denoted a and a . String constants were delimited by double-quotes, and double-quotes within a line were escaped with a second double-quote. Variable declarations could use constants to define an initial value, as in . Note the use of the assign-to rather than is-a. Additionally, SPL had a keyword that allowed a string of text to be defined as a variable, and then replaced any instances of that variable in the code with the literal string during compiles. This is similar to the keyword in C. Memory segmentation The classic HP 3000 organized physical memory into 1, 2, 4, 8 or 16 banks of 64K (65536) 16-bit words (128K bytes). Code (shared, non-modifiable) and data were separate from each other and stored in variable-length segments of up to 32K words each. Within a process, data addresses such as pointers were 16-bit offsets from a base regsiter (known as DB), or relative offsets from a pointer register (Q or S) that resulted in a valid address within the process's data area (called the stack). While primarily 16-bit word-oriented, the system supported addressing of individual bytes in an array by using the word address where the byte was stored shifted left 1 bit then adding 0 to access the upper byte, or 1 for the lower byte. Thus byte addresses were separate and distinct from word addresses and the interpretation of an address was purely contextual. This proved to be quite troublesome and was the source of numerous bugs in both system and user code. Care had to be taken to treat byte addresses as 16-bit unsigned (that is, type LOGICAL) when using them in,