Talk:List of ARM microarchitectures
|This article is of interest to the following WikiProjects:|
|Text and/or other creative content from this version of ARM architecture was copied or moved into List of ARM microprocessor cores with this edit on 13 June, 2011. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted so long as the latter page exists. The former page's talk page can be accessed at Talk:ARM architecture.|
Cortex release dates
Request: A date for the release of each Cortex architecture will be very helpful. http://en.wikipedia.org/w/index.php?title=Talk:List_of_ARM_microprocessor_cores&action=submit# — Preceding unsigned comment added by 126.96.36.199 (talk) 16:03, 10 January 2013 (UTC)
- You can search through press releases at http://www.arm.com/about/newsroom/
- You can contact ARM at http://www.arm.com/contact-us/
- • Sbmeirow • Talk • 22:14, 10 January 2013 (UTC)
- Thanks for that, but the layout made it a little difficult to read. So I broke the cores into columns for the embedded, real-time, and application cores. And each year is restricted to a single row. I think this makes it easier to read and understand the information. Now, to add older cores. Should third-party cores be included? --Imroy (talk) 05:10, 6 April 2014 (UTC)
Again, I think a single combined table looks much better than lots of small tables. It fits much better with calling the section a "timeline", allowing readers to see the information quickly and easily.
How about this?
|Year||Classic cores||Cortex Cores|
- Sorry that I didn't reply sooner. I didn't see this table when you posted it. Yes, your unified table looks better, except (1) the double vertical line isn't needed between classic and cortex, (2) we need to pull my comments out into a one comment section so we'll all know which cores are missing, (3) I wonder if a 64bit App Core column should be added on the right side (thoughts?), (4) should rows be added for the missing years (thoughts?), (5) should we plan for older cores on the left side or just start with ARM7 (I think skipping ARM6 and older is fine otherwise too many columns and rows) (thoughts?). • Sbmeirow • Talk • 19:02, 19 April 2014 (UTC)
ARM2, ARM3 relationship to ARM250
The ARM250 is not more related to the ARM2 than the ARM3. In fact it is an ARM3 without the cache. "It is interesting to notice that the ARM3 doesn't 'perform' faster - both the ARM2 and the ARM3 average 0.56 MIPS/MHz. The speed boost comes from the higher clock speed, and the cache." http://www.heyrick.co.uk/assembler/proctype.html Maybe the ARM250 should be put in the ARM3 Family? Jonpatterns (talk) 14:33, 8 April 2013 (UTC)
Cortex-M with Cache
ARM doesn't sell a design for cache for M0-M4, but they did keep all the signals you'd need to hook one up available, and so there are some Cortex-M cores with caches, just not caches designed by ARM. Most Cortex-M's running on flash have a very small instruction prefetch cache like ART on STM32, and some Cortex-M's with external memory interfaces have general-purpose(both instructions and data) caches. Could we phrase this better instead of "No Cache"? Maybe "Optional caches" or "SoC-provided caches"? Rsaxvc (talk) 05:49, 16 March 2014 (UTC)
Refactor ARM Core Tables?
Would it make sense to refactor the "Cache (I / D), MMU" of ARM Cores Designed by ARM" column into multiple columns? It seems like it has become overgrown with things like TCM, ECC and MMU extensions all in the same column. Trustzone also appears in multiple columns, perhaps because it has no home. Rsaxvc (talk) 04:54, 30 September 2014 (UTC)
- It's a tough call of what columns to add, since not all flavors have some features. ECC/Parity are related to Cache and TCM, so it belongs in those columns. Possibly: Cache, TCM, MMU, FPU, Instruction Set. Another thing to consider is duplicating a section, so we can support more columns. I think more people should respond and we get a game plan together, like agree on a column list from left to right before a major overhaul starts! The bigger the table, the more work and risk of mistakes, so best to not get in a big hurry. • Sbmeirow • Talk • 05:55, 30 September 2014 (UTC)