From WikiChip
Difference between revisions of "Talk:arm/armv1"
< Talk:arm

(Corrections needed with the address space)
Line 6: Line 6:
 
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. [[User:Alec|Alec]] ([[User talk:Alec|talk]]) 13:22, 27 June 2017 (EDT)
 
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. [[User:Alec|Alec]] ([[User talk: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 -> {{arm|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. --[[User:David|David]] ([[User talk:David|talk]]) 13:50, 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 -> {{arm|26-bit architectures}} (That's the term ARM used to describe those legacy architectures at the time, not ours). 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. --[[User:David|David]] ([[User talk:David|talk]]) 13:50, 27 June 2017 (EDT)

Revision as of 12:55, 27 June 2017

This is the discussion page for the arm/armv1 page.
  • Please use this page to discuss possible errors, inconsistencies, omissions, changes, and further clarifications regarding the content of arm/armv1.
  • If you are looking for a particular model that's missing, please add its name to this 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 (That's the term ARM used to describe those legacy architectures at the time, not ours). 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)