Variable size/Set: Difference between revisions
→{{header|ARM Assembly}}
Puppydrum64 (talk | contribs) |
Puppydrum64 (talk | contribs) |
||
Line 146:
<lang ada>type Response is (Yes, No); -- Definition of an enumeration type with two values
for Response'Size use 1; -- Setting the size of Response to 1 bit, rather than the default single byte size</lang>
=={{header|ARM Assembly}}==
Syntax will vary depending on your assembler. VASM uses <code>.byte</code> for 8-bit data, <code>.word</code> for 16-bit data, and <code>.long</code> for 32-bit data, but this is not the norm for most assemblers, as a "processor's word size" is usually the same as its "bitness." I'll use the VASM standard anyway, just because. When defining data smaller than 32-bits, there needs to be sufficient padding to align anything after it to a 4-byte boundary. (Assemblers often take care of this for you, but you can use a directive like <code>.align 4</code> or <code>.balign 4</code>to make it happen.
<lang ARM Assembly>.byte 0xFF
.align 4
.word 0xFFFF
.align 4
.long 0xFFFFFFFF</lang>
Keep in mind that although you may have <i>intended</i> the data to be of a particular size, the CPU does not (and cannot) enforce that you use the proper length version of <code>LDR/STR</code> to access it. It's perfectly legal for the programmer to do the following:
<lang ARM Assembly>main:
ADR r1,TestData ;load the address TestData
LDRB r0,[r1] ;loads 0x000000EF into r0 (assuming the CPU is operating as little-endian, otherwise it will load 0x000000DE)
BX LR
TestData:
.long 0xDEADBEEF</lang>
The reverse is also true; you can point a register to the label of a <code>.byte</code> data directive and load it as a long, which will give you the byte along with the padding that it would receive to keep everything aligned. Generally speaking, you don't want to do this, as it can lead to problems where a register doesn't contain what the code assumes it does. However, being able to ignore typing at will can be advantageous, such as when trying to copy large blocks of consecutive memory, where you can achieve more throughput by copying 32 bits per instruction instead of only 8 or 16.
=={{header|AutoHotkey}}==
| |||