Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!princeton!phoenix!tbrakitz From: tbrakitz@phoenix.Princeton.EDU (Byron Rakitzis) Newsgroups: comp.sys.apple2 Subject: Re: apple // and multitasking, perfect together! (??????????) Message-ID: <14330@phoenix.Princeton.EDU> Date: 7 Mar 90 02:47:05 GMT References: <14298@phoenix.Princeton.EDU> Reply-To: tbrakitz@phoenix.Princeton.EDU (Byron Rakitzis) Organization: Princeton University, NJ Lines: 43 In article pnakada@oracle.com (Paul Nakada) writes: > >This is actually kind of cool, the concept of all memory acces being >done through load and store instructions. That would allow This is exactly what MIPS does. It's not my idea, but it's obviously suitable under the circumstances. > >I think that some sort of elementary VM is necessary for any type of >multiprocess OS on the //. > I am aiming at a full blown VM!! This is my dream: to hack up a card for one of the expansion slots which would communicate with the phone port in the back of my Mac SE... The SE would act as the //'s filesystem! That way the // could tell the card to fetch page x, and then get on with other business while all that stuff is done by the other hardware. The memory copies can then be done really fast with a tight loop. I want to steer clear of Disk ][ if I'm going to implement VM. >Will your BISC instruction set be a p-machine? (interpreted) or >compiled directly to assembly. The former is more suited to a VM >environment. > BISC will definitely be interpreted. With an MMU and other sundry interrupt handlers (keyboard etc.) it would be insane to compile the BISC into 6502. I am aiming for code which is really compact at the BISC level. That's another reason for the RISC design, paradoxically enough. If I allow only register-register arithmetic instructions, then I can squeeze a whole class of opcodes into two bytes, if I'm careful. (though that might mean having only 16 16-bit registers) >-Paul Nakada >pnakada@oracle.com -- Just try taking your VAX down to Jiffy-Lube these days! Byron "Bo knows parallel computational geometry" Rakitzis. (tbrakitz@phoenix.Princeton.EDU)