From WikiChip
Difference between revisions of "Talk:arm/armv1"
Line 1: | Line 1: | ||
+ | {{talk header}} | ||
+ | |||
==Corrections needed with the address space== | ==Corrections needed with the address space== | ||
x86 is exceptional in that it doesn't really care about alignment, not just of instructions (they're variable length, it has no choice) but of data. Many RISC architectures would work with units of 4 bytes, as such they only needed 30 bit addresses. I've seen some archs that have instructions for load the high 2 bytes, load the low 2 bytes of a 4 byte range. | x86 is exceptional in that it doesn't really care about alignment, not just of instructions (they're variable length, it has no choice) but of data. Many RISC architectures would work with units of 4 bytes, as such they only needed 30 bit addresses. I've seen some archs that have instructions for load the high 2 bytes, load the low 2 bytes of a 4 byte range. |
Revision as of 13:51, 27 June 2017
This is the discussion page for the arm/armv1 page. |
|
Corrections needed with the address space
x86 is exceptional in that it doesn't really care about alignment, not just of instructions (they're variable length, it has no choice) but of data. Many RISC architectures would work with units of 4 bytes, as such they only needed 30 bit addresses. I've seen some archs that have instructions for load the high 2 bytes, load the low 2 bytes of a 4 byte range.
Anyway when considering how much memory it can address it probably should be 2^28, not 2^26, so that's 256 mb not 64 mb - that or it has a 24 bit program counter. Alec (talk) 13:22, 27 June 2017 (EDT)
- You're correct about the evaluation and about the later conclusion. The ARM1 (through ARM3) actually do indeed have only 24-bit program counters. Because instructions are always 4 bytes, the two low-bits are always 0 so they're simply shifted left by 2. We've started documenting that here -> 26-bit architectures. In the very first few architectures, Acorn used the remaining 8 bits of the program counter to store the program state. Which was a really nice feature at the time, allowing subroutines entry/exit to save states automatically. --David (talk) 13:50, 27 June 2017 (EDT)