Read more.Quote:
Chances in the server market won’t be hurt by decision to stick with 32-bit, at least for now.
Printable View
Read more.Quote:
Chances in the server market won’t be hurt by decision to stick with 32-bit, at least for now.
I'd be happier if they were at least considering 64-bit. Presumably ARM 32-bit has the same memory limitations as x86 32-bit, and I'm pretty sure in a few years I'll be considering whether to get an ARM-based tablet/notebook running Windows 8, or an x86 one, and if the ARM one is limited to ~3GB RAM it's likely the x86 one will be getting my money. And it seems it takes a couple of years for even a completed design to make it into products, so it doesn't seem like they have that much time on their side..
If mobile phones ever need >4GB of RAM any time soon, then we'd need to seriously re-evaluate mobile/embedded development.
In a couple of generations it seems likely that ARM will be powerful enough for mainstream laptops. Combined with a desktop version of Windows that will run on ARM, and potentially superior pricing/battery compared to what x86 may be offering at that time, 4GB RAM on ARM may not be that far away.
Strictly speaking, ARM is already plenty powerful enough for laptops, and even most common desktop tasks. The problem is that software has become bloated beyond epic proportions. And I don't even hold distinction for Windows, or OS X. Linux has also been suffering from perpetual feature creep and abstraticitis.
Also there is a confusion about 64bit been required to address more memory.
Segmented memory models, who here actuallys codes pointer arthimatic or machine code for anything other than ****s and giggles now adays? So why not just segment?
I can merrily chug away calcing a 256bit int on my 8bit MCU if I wish, it is just a lot slower.
For browsing the web and such do we need this? No. For games and such its floating point which is a whole different ball game all together. This combined with the fact that the vast majority of ARM sales are no doubt going into systems that have maybe 32meg of RAM, serially addressed EEPROM and the like, I doubt they are really doing any work with 64bit values. Few people have need for 64bit integers, normally its floating points and these ARM sucks at anyway.
If we are seeing more people moving from Desktops to portable devices which just render web pages, flash, silverlight, java. Then for this entire market there is no need for 64bit arithmatic on integers at high performance. The business model of ARM licensing IP means that someone will produce a combination of it with some graphics chip for all the specific maths.
Also floating point is slow, the trick to speading it up is to make bits that run in parallel doing specific tasks, this increases the instruction set space and quickly you are no longer a RISC design, with all the costs and downsides ascoiciated.
For windows 8 I'm trying desperately to think of a frequently called API that even takes a floating point number for something other than graphics, I can't. I'm trying to think of something that requires a 64bit for something other than file addressing / its-the-pointer size. I can't.
>4GiB Native memory addressing? ;)
in a way native memory addressing is overrated, your CPU will fetch pages of data into the cache, and shift blocks of data between caches, its not like it shifts them 64bits at a time, that would be very inefficent.
segmented memory models aren't the evil people seem to claim. On the higher end PICs I used to use (and I believe this is still the case) you'd flip which set of memories were active. Not just lacking a flat memory model but also segmentation on certain locations! I used to find them great and enjoyable in MASM despite these issues.
It's still more efficient, should you ever have the need. Although nobody should consume a whole 4GB opening a browser and a few tabs.
ah but is it in actually a power level way.
remember moving 64 paths of silicon is going to take more power draw than 32. If we have a segmented model, there is no hit in talking to the memory, only on the pointery stuff.
think LEA in x86 or Load Effective Address, a de-referencing load value instruction, very handy.
in ARM how often would you be crossing the memory segment in a pointer use? I'd guess about 5% right now, but lets be generious and say its 50%.
Overall I'd guess/assume that it would be more power efficent to use a 32bit core with segmentation.
All this talk of segmented memory models is confusing me. Forget all these clock-cycle-sucking pointers and segments, surely all that is needed to access more physical memory is a new MMU with page tables that can translate a flat 32-bit virtual address space into a larger physical address space. Then you can keep the 32-bit CPU architecture without any messy CISCy extensions and just remap a section of virtual address space between threads/tasks the same way you would currently with a 32-bit physical memory map. The L1 cache stays 32-bit too as long as that caches virtual addresses. (Actually I've just read up on the Cortex A15 and blow me if this isn't exactly how it works)
If you're advocating a change to the ARM architecture, it's probably time to create a whole new 64-bit mode with 64-bit registers and everything. You could keep the 32-bit instruction space, Thumb-stylee, or even go VLIW. In terms of performance/watt I think it's probably better than mucking about with segments and pointers. Double the width of the data path and keep a 32-bit instruction bitmap and you'd much less than double the number of transistors and therefore less than double power consumption per core. If you perform extra register reads and arithmetic to implement segmented memory addressing, you need to do more work, so you either need a more complex pipeline and more register read ports, or more clock cycles. Power consumption increases exponentially with clock speed, so performance/watt might suffer more than a straightforward orthogonal 64-bit design with all its side-benefits. Don't forget that segmentation could also seriously impact your L1 data cache.
I'm not saying I know it definitely would be worse, but that is CISC vs RISC.
Aside: I'm not sure what's wrong with floating point performance on high performance ARMs nowadays. I've not played with either the Cortex A8 or A9 myself, but I understand the A8 core can retire two single-precision arithmetic ops per instruction per cycle using NEON. Cortex A9 is meant to be faster at VFP instructions and A15 even more so, but I haven't looked at the timings.
welcome to hexus, nice first post!
MMU using a page table with addressing is kinda a segmentation model right there, the difference is rather than having an A:B for want of a phrase approch we have a set of mapping values, or at least such is my understanding of this (its been too long since I was down n dirty).
Surely changing the ARM to 64bit would be a massive undertaking and drastically increase the transistor count, at the end of the day in my mind if your only needing a 16bit op, and your using 32bits of registers there are going to be many more state changes of silicon than need be, all those yaws taking energy, generating heat, for something you don't really need.
Given how seldomly your donig pointer arthmitec across pages (if you were doing it a lot on an ARM 32kb of cache wouldn't be enough!) the cost of having to emulate higher bit precision is minimal surely? Also when you consider how often it would be 64bit int + 32bit int, rather than 64bit + 64bit.
To me its an efficeny thing, which is the most statistically likely to happen overall for battery performance, and which is likely to be needed in a bottleneck for performance. For ARM surely at the moment it is the battery concern which would outweight a small perfromance hit in unusual circumstances.
asside: on the FLOPs I think they have really improved this by going for a vector approche, but I've not had cause to play with one, either way, compared to a desktop PC with descrite GPU its just not in the same league by a mile.