ARM-based desktop computer ? (Hybrid computers ?: Low + Highperformance ;))
|
Prev: ARM-based desktop computer ? (Hybrid computers ?: Low + High performance ;))
Next: Simple Hack to get $500 to your home
From: Ken Hagan on 10 Jun 2010 04:50 On Wed, 09 Jun 2010 17:25:25 +0100, Benny Amorsen <benny+usenet(a)amorsen.dk> wrote: > MooseFET <kensmith(a)rahul.net> writes: > >> Such programs already exist. It is a clever trick that is used to make >> fast simulations of the ARM on a PC. Doing it the other way also can >> be done. It wouldn't be super fast but if you weren't trying to run a >> complete Windows OS, it could be fast enough to be used. > > Most ARM implementations today still come without an FPU. x86 software > from the last decade tends to rely on a real FPU, so that could be a > showstopper. I fail to see how. Since you are emulating everything anyway (or translating it to native code) I don't see how occasional floating point instructions would cause a problem, and I'd be astonished if very much x86 software is performance-limited by the FPU. Even something like Excel is going to be mostly bookkeeping rather than computation. No, I think your real problem is that "modern" Windows relies on a 300W graphics card and solid state disc to boot as far as the desktop and file explorer within a reasonable time-scale. Twenty years ago it was commonplace for major applications to come with a hardware spec on the box, because their needs were significantly greater than the base OS. You don't see that now, because the "OS" is the major consumer of cycles, RAM and disc. If you can boot the OS then the additional needs of even quite heavyweight applications are just noise. Of course, followers of this group are probably in the small minority for whom this isn't actually true.
From: nmm1 on 10 Jun 2010 06:24 In article <op.vd2th7qoss38k4(a)khagan.ttx>, Ken Hagan <K.Hagan(a)thermoteknix.com> wrote: >On Wed, 09 Jun 2010 17:25:25 +0100, Benny Amorsen ><benny+usenet(a)amorsen.dk> wrote: >> MooseFET <kensmith(a)rahul.net> writes: >> >>> Such programs already exist. It is a clever trick that is used to make >>> fast simulations of the ARM on a PC. Doing it the other way also can >>> be done. It wouldn't be super fast but if you weren't trying to run a >>> complete Windows OS, it could be fast enough to be used. >> >> Most ARM implementations today still come without an FPU. x86 software >> from the last decade tends to rely on a real FPU, so that could be a >> showstopper. > >I fail to see how. Since you are emulating everything anyway (or >translating it to native code) I don't see how occasional floating point >instructions would cause a problem, and I'd be astonished if very much x86 >software is performance-limited by the FPU. Even something like Excel is >going to be mostly bookkeeping rather than computation. Forget the performance - that's not the issue. It's the fact that the way that floating-point is 'supported' relies on a large amount of crud in the kernel (i.e. the interrupt-based fixup code). While most kernels have a policy that floating-point should not be used in most of their code, to avoid relying on that, I suspect that many modern ones use a fair amount of non-interrupting floating-point by accident. And, if you have to emulate even THAT by interrupt, then they will fail horribly. That also ignores the problem that most modern interrupt handling is totally borked, and I would expect serious problems when taking such an interrupt in even a user-code interrupt handler. Again, some such handlers probably use non-interrupting floating-point by accident, and would then fail. All fixable, and used to be SOP in the past, but modern code would need cleaning up to the same level as then to work without a FPU. Regards, Nick Maclaren.
From: Ken Hagan on 11 Jun 2010 05:06 On Thu, 10 Jun 2010 11:24:06 +0100, <nmm1(a)cam.ac.uk> wrote: > In article <op.vd2th7qoss38k4(a)khagan.ttx>, > Ken Hagan <K.Hagan(a)thermoteknix.com> wrote: >> On Wed, 09 Jun 2010 17:25:25 +0100, Benny Amorsen >> <benny+usenet(a)amorsen.dk> wrote: >>> Most ARM implementations today still come without an FPU. x86 software >>> from the last decade tends to rely on a real FPU, so that could be a >>> showstopper. >> >> I fail to see how. Since you are emulating everything anyway (or >> translating it to native code) ... > > Forget the performance - that's not the issue. It's the fact that > the way that floating-point is 'supported' relies on a large amount > of crud in the kernel (i.e. the interrupt-based fixup code). I still don't follow. I've snipped the thread (above) so if I've snipped something significant then that will give you a clue. My take is that if you are running x86 code on an ARM then you are emulating everything already, taking each x86 instruction and spitting out some ARM code that modifies a virtual x86 CPU context. x87 instructions merely widen the scope of that programming problem. Since emulation is slow, presumably you'd identify the "easy code" (non-self-modifying and no crazy jumps to the middle of other instructions) and use pre-translation rather than emulation, but you'd still just be modifying a virtual CPU context. I don't see how fix-ups and interrupts affect anything, since interrupts in a virtual CPU are just more user-mode in the real CPU. VMware has done this for years. Here the "translation" is trivial for user-mode code, but for kernel mode stuff it has to do it the hard way. There's a performance hit, but it is affordable and it would still be affordable on ARM because the user-mode code would still be translatable (less trivially, but still just an exercise in language translation) to something that ran natively rather than being emulated instruction by instruction. I assume that the only reason we don't already have things like VMware and VirtualBox running on ARM hosts is that there's no market. People tend not to buy ARM-based machines if they know they need to run closed source x86 code.
From: nmm1 on 11 Jun 2010 09:25 In article <op.vd4owvrvss38k4(a)khagan.ttx>, Ken Hagan <K.Hagan(a)thermoteknix.com> wrote: >>> >>>> Most ARM implementations today still come without an FPU. x86 software >>>> from the last decade tends to rely on a real FPU, so that could be a >>>> showstopper. >>> >>> I fail to see how. Since you are emulating everything anyway (or >>> translating it to native code) ... >> >> Forget the performance - that's not the issue. It's the fact that >> the way that floating-point is 'supported' relies on a large amount >> of crud in the kernel (i.e. the interrupt-based fixup code). > >I still don't follow. I've snipped the thread (above) so if I've snipped >something significant then that will give you a clue. > >My take is that if you are running x86 code on an ARM then you are >emulating everything already, taking each x86 instruction and spitting out >some ARM code that modifies a virtual x86 CPU context. x87 instructions >merely widen the scope of that programming problem. Since emulation is >slow, presumably you'd identify the "easy code" (non-self-modifying and no >crazy jumps to the middle of other instructions) and use pre-translation >rather than emulation, but you'd still just be modifying a virtual CPU >context. I was assuming that "x86 software" meant "software that currently runs on x86 systems" rather than "x86 binaries". I.e. the software, from kernel to application, would usually be recompiled. With your interpretation, what you say is more-or-less true, but there are still some nasty traps. Regards, Nick Maclaren.
From: Jasen Betts on 16 Jun 2010 07:11
On 2010-06-08, Skybuck Flying <IntoTheFuture(a)hotmail.com> wrote: > Is this the end of Windows because it doesn't work on ARM processors ? wince. --- news://freenews.netfront.net/ - complaints: news(a)netfront.net --- |