If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

I think that it is more likely intended for mobile devices, where the entity who has control over the device runs the user interface/media/DRM/etc. functions in one VM, while the owner can run his own applications in a separate sandboxed VM.

Comment

Don't kid yourself. PAE is a horrible crutch on x86 and will be the same on ARM.
ARM64 (like MIPS64) with a properly though-out 32-bit compat layer (for all existing
applications) would have been a much better idea, but I guess they needed a quick
solution on top of the existing arm ecosystem to keep their biggest licensees happy.

Comment

This would mean that the ARM architecture is split between ARM32 and ARM64, because ARM's that don't support 64-bit then fail to run Linux. But anyway, when NVidia's Project Denver ARM64 CPU comes out somewhere around 2013, I am sure that there will be someone starting ARM64 development in the kernel.

Comment

This would mean that the ARM architecture is split between ARM32 and ARM64, because ARM's that don't support 64-bit then fail to run Linux. But anyway, when NVidia's Project Denver ARM64 CPU comes out somewhere around 2013, I am sure that there will be someone starting ARM64 development in the kernel.

It's still 32bit instruction set, just the address space the MMU can handle has been
extended. This is not uncommon (I have a MIPS32 system which has a 36bit address space, 32bit PPC can do the same I believe), but applications are still limited to their theoretical 4GB, which is a bit useless for larger server-type stuff (think working with large matrices, caches, ...).
I'm pretty sure prototype code to support linux on ARM64 exists. After all, if you have
the HDL to describe the CPU, you can simulate it or run it on a slow FPGA.