Semiconductor & Computer Engineering
From WikiChip
Difference between revisions of "Talk:arm/armv1"
(→Corrections needed with the address space) |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| 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) |
| + | |||
| + | |||
| + | :It's 26-bit logical PC / 24-bit physical PC, ARM uses the first version to describe it so that's what I went by. We can add a note about it. --[[User:At32Hz|At32Hz]] ([[User talk:At32Hz|talk]]) 14:58, 27 June 2017 (EDT) | ||
| + | |||
| + | : Hey guys, I just created the page this morning. I didn't get to finish everything until I came back from work. Took me a while to sort out all the instructions for each version and determine which ones is which version (got a messy excel sheet lol). --[[User:At32Hz|At32Hz]] ([[User talk:At32Hz|talk]]) 19:35, 27 June 2017 (EDT) | ||
Latest revision as of 18:35, 27 June 2017
| This is the discussion page for the arm/armv1 page. |
|
Corrections needed with the address space[edit]
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)