From: Bruce Horrocks on 30 Jan 2010 19:22 On 30/01/2010 06:39, James Taylor wrote: > Bruce Horrocks wrote: > >> James Taylor wrote: >> >>> So, despite the fact that the iPhone OS *is* a multitasking OS, the GUI >>> actively quits applications you are using as you switch. Apple must have >>> done *extra* work to include that feature. >> >> Not necessarily. Unix is a multi-tasking OS but only on CPUs that >> support it. > > Eh? No modern processor lacks the ability to run a multitasking OS. > Indeed it is hard to imagine any processor architecture in the history > of computing where multitasking is impossible. Unix has been around for > a long time and I've never heard of it not multitasking. Please explain. > >> [1] Okay, so back in SystemIII days it might have run on non-VM >> processors I apologise for pulling you up on your statement. You are correct for all practical purposes. If you had claimed that all non-electric cars use internal combustion engines then my response was the equivalent to pointing out that there are still a few steam powered cars lurking around in museums. Technically correct but mostly confusing the argument. > What exactly is a non-VM processor? Are you talking about the > virtualization support of the latest 64 bit Intel (VT-x) and AMD (AMD-V) > processors, or the virtual memory management employed by operating > systems? The former is not required for multitasking, and the latter is > not a feature of the CPU anyway. Also virtual memory management and is > an independent concept to multitasking so you can have either virtual > memory, or multitasking, or both. Neither feature is required for the > other to work. They are entirely orthogonal. > >> but back then malware didn't exist. > > What has malware got to do with it? You can run malware on any > processor, and on any OS, regardless of whether it multitasks. Early hardware support for multi-tasking didn't support virtual machines in the hardware so one process could reasonably easily see another's address space. Fine back in those days but unworkable now. Again an obtuse argument. > >> [1] It's possible, that the bits Apple added to the ARM core in their >> A4 chip are effectively single-tasking, > > ARM specialises in low latency interrupt handling, and large numbers of > registers in separate banks for the various processor modes, all of > which allows particularly efficient multitasking. As a RISC OS user for > many years, and ARM assembly programmer, I should know. > >> perhaps because so much work has been off-loaded from software to >> silicon in the search for speed, that context switching becomes >> prohibitively expensive. > > Each new generation of ARM architecture gets better and faster at this > kind of thing, not worse. I cannot imagine where you get your strange > ideas, and I think you should explain yourself. The ARM core does indeed get better - but if you look closely I said the 'bits Apple added to the ARM core'. Apple's A4 chip almost certainly doesn't change the ARM core. But it can add other functionality. Trivially, for example, HP recently had Atmel add 7-segment display support to one of their low-power ARMs. So what additions might Apple want to make and how might they impact multi-tasking? Well, the multi-touch screen is one obvious candidate for h/w support. Another might be replacing sections of core Cocoa library routines with dedicated silicon. It doesn't really matter what the change is, my point was to suggest that Apple may have optimised so much that multi-tasking was compromised. It's not that multi-tasking has been made impossible, just that the speed benefits are lost if it is enabled. Hence my comment about context switch times. This, of course, and I freely admit, is pure speculation. In a few years we may find out from Apple themselves as to why the single-tasking limitation exists. Another strange idea brought to you from my sock drawer. -- Bruce Horrocks Surrey England (bruce at scorecrow dot com)
From: James Taylor on 30 Jan 2010 21:27 Bruce Horrocks wrote: > James Taylor wrote: > >> So, despite the fact that the iPhone OS *is* a multitasking OS, the GUI >> actively quits applications you are using as you switch. Apple must have >> done *extra* work to include that feature. [...] >> Each new generation of ARM architecture gets better and faster at this >> kind of thing, not worse. I cannot imagine where you get your strange >> ideas, and I think you should explain yourself. > > The ARM core does indeed get better - but if you look closely I said the > 'bits Apple added to the ARM core'. Apple's A4 chip almost certainly > doesn't change the ARM core. But it can add other functionality. The point is that functionality is added but rarely is it taken away. > So what additions might Apple want to make and how might they impact > multi-tasking? Well, the multi-touch screen is one obvious candidate for > h/w support. Another might be replacing sections of core Cocoa library > routines with dedicated silicon. It doesn't really matter what the > change is, my point was to suggest that Apple may have optimised so much > that multi-tasking was compromised. But surely even the standard iPhone OS multitasks in the true sense of the word (running system daemons, etc). So what we're talking about here is whether it "multitasks" in the sense of running more than one GUI application at a time from the point of view of the user. > It's not that multi-tasking has been made impossible, just that the > speed benefits are lost if it is enabled. Hence my comment about > context switch times. I don't believe any such limitation exists, not even in the software, let alone the hardware. I believe the GUI behaviour of quitting one application as you switch to another is simply a design decision to make use of the phone simpler for people. That way users do not have to think about process management, saving memory, CPU usage, or battery life. -- James Taylor
From: Richard Tobin on 31 Jan 2010 06:36 In article <7sk0prF75pU1(a)mid.individual.net>, Bruce Horrocks <07.013(a)scorecrow.com> wrote: >Early hardware support for multi-tasking didn't support virtual machines >in the hardware so one process could reasonably easily see another's >address space. The term "virtual machine" already has two common uses. Using it to refer to protected address spaces is just confusing. -- Richard -- Please remember to mention me / in tapes you leave behind.
From: Chris Ridd on 31 Jan 2010 08:14 On 2010-01-31 11:36:56 +0000, Richard Tobin said: > In article <7sk0prF75pU1(a)mid.individual.net>, > Bruce Horrocks <07.013(a)scorecrow.com> wrote: > >> Early hardware support for multi-tasking didn't support virtual machines >> in the hardware so one process could reasonably easily see another's >> address space. > > The term "virtual machine" already has two common uses. Using it to refer > to protected address spaces is just confusing. I expect Bruce meant virtual memory. -- Chris
From: Ian McCall on 31 Jan 2010 11:51
On 2010-01-31 13:14:30 +0000, Chris Ridd <chrisridd(a)mac.com> said: > On 2010-01-31 11:36:56 +0000, Richard Tobin said: > >> In article <7sk0prF75pU1(a)mid.individual.net>, >> Bruce Horrocks <07.013(a)scorecrow.com> wrote: >> >>> Early hardware support for multi-tasking didn't support virtual machines >>> in the hardware so one process could reasonably easily see another's >>> address space. >> >> The term "virtual machine" already has two common uses. Using it to refer >> to protected address spaces is just confusing. > > I expect Bruce meant virtual memory. Mode. Virtual mode: <http://en.wikipedia.org/wiki/Virtual_8086_mode> Cheers, Ian |