SASQUATCH@ALBION.BITNET ("Kevin O. Lepard 629-5511 x6668", 517) (03/19/89)
Would it be possible to write a program similar to softswitch that could automatically switch between applications, allowing something to run in background? I've heard people talk about "heartbeat" interrupts. Couldn't that be used somehow? Even if this cut the speed of the GS in half, it would still be running as fast as a normal //e Just musing out loud. That'd be heck of a nice program if someone could di (that's "do") it. I'd love to be able to download, etc, in the background. Kevin Lepard Bitnet: Sasquatch@albion.bitnet
dcw@athena.mit.edu (David C. Whitney) (03/30/89)
In article <8903181259.aa27052@SMOKE.BRL.MIL> SASQUATCH@ALBION.BITNET ("Kevin O. Lepard 629-5511 x6668", 517) writes: > >Would it be possible to write a program similar to softswitch that could >automatically switch between applications, allowing something to run in >background? I've heard people talk about "heartbeat" interrupts. Couldn't >that be used somehow? Even if this cut the speed of the GS in half, it >would still be running as fast as a normal //e I think everyone here needs a bit of enlightenment. As much as I would LOVE a multitasking environment on my //GS, I *know* that it can't be done within any reasonable degree of efficiency. Even Macintoshes don't have "true" multitasking (ie, Multifinder is a good hack, but it isn't "for real"). Only Mac IIs with the PMMU installed (or any IIx - 68030) can even *hope* to do multitasking. The problem? A system for handling virtual memory is a MUST for multitasking. Now, a virtual memory handler *could* be written in assembler, but one running on a screeching 68030 going at 45MHz still wouldn't go fast enough to make the machine come within tolerable speed limits. That's why there is the PMMU - that's Paged Memory Managment Unit. It handles page faults in hardware, so things go reasonably fast (although most A/UX people will tell you it's still too slow). The next problem is designing a way to quickly make calls to the OS. The Mac (more accurately, the 680x0 series), along with 80x86 machines use something called "traps." They are basically undefined processor instructions that can be defined by the host computer. The Mac implements its toolbox calling by using traps. As far as I know, the 65816 doesn't have a trap mechanism (although, I suppose the COP instruction might get useful here...). Apple is going to release a new system sometime that uses the 68030 (or PMMU) to do virtual memory stuff. Sometime after that, MultiFinder will be a thing of the past, as *real* multitasking will be here. This is relatively easy to do on the Mac while it's remarkably hard on the //GS. So hard in fact that nobody should even bother. Sorry to rain on your parade, but a multitasking OS is a physical impossibility on the // line. IT CAN'T BE DONE. Now, expend that creative energy on porting GNU C and GNU Emacs, and I'll be VERY VERY happy! Dave Whitney A junior in Computer Science at MIT dcw@athena.mit.edu ...!bloom-beacon!athena.mit.edu!dcw dcw@goldilocks.mit.edu I wrote Z-Link & BinSCII. Send me bug reports. I use a //GS. Send me Tech Info. "This is MIT. Collect and 3rd party calls will not be accepted at this number."
jac@paul.rutgers.edu (J. A. Chandross) (03/30/89)
SASQUATCH@ALBION.BITNET ("Kevin O. Lepard 629-5511 x6668", 517) writes: > >Would it be possible to write a program similar to softswitch that could >automatically switch between applications, allowing something to run in >background? I've heard people talk about "heartbeat" interrupts. Couldn't >that be used somehow? Even if this cut the speed of the GS in half, it >would still be running as fast as a normal //e Dave Whitney (dcw@athena.mit.edu) >calling by using traps. As far as I know, the 65816 doesn't have a trap >mechanism (although, I suppose the COP instruction might get useful here...). You are forgetting about the BRK instruction. This causes a software interrupt. What you do is set a flag (ie global variable) and then execute the BRK. The semaphore tells the OS exactly what sort of interrupt you *really* wanted to generate. This is a nice way to expand the instruction set. An an article on how to do this appeared in Byte about 10 years ago. The basic idea is that you put the opcode of the fake instruction and it's data right after the BRK. When you get the interrupt your interrupt handler looks at the value of the PC on the stack (remember, all registers are saved by the interrupt) and grabs the instruction/opcode from memory, and simulates it. When the simulated instruction is finished it jumps to the address of the old PC + the size of the simulated instruction (including operands, etc.) Software traps for non-existant instructions are usually faster than a subroutine since the subroutine has to set up an activation record (at least for compiled code; assembly programmers are much craftier.) >Sorry to rain on your parade, but a multitasking OS is a physical impossibility >on the // line. IT CAN'T BE DONE. Now, expend that creative energy on porting >GNU C and GNU Emacs, and I'll be VERY VERY happy! Sorry to rain on *your* parade, but you are very wrong here. The early versions of Unix supported multitasking. Even in 1969. Even with no memory protection and memory management of any sort. Even in < 64K. So how did they do it? You make your system a total swapping system. Whenever you get the interrupt to change jobs you put the current contents of memory out on disk and load in the next job to run. The only "constant" code is the operating system. Now, a bogus pointer can still trash the OS, but this was a problem with early Unix too. (Basically, you don't allow anyone to test code while you are doing real work.) The only problem with a swapping on the ][+ is that all I/O is synchronous since the processor is doing it. This means that while one process is waiting on a disk access you can't run another because you would have to swap it in off disk, and that requires a disk access, which... But this isn't a real problem. It is very difficult for an Apple to support multiprogramming (ie more than one job in core at time same time) more complicated than of the TSR (Terminate and Stay Resident) variety because of limited memory. However, one could use it with a few small jobs (like 5 k apiece). An Apple with a RocketChip (plug, plug) or a Zip Chip, or a Transwarp, etc is a kick-ass machine compared to the early PDP-11's. The early 11's took tens of microseconds to add 2 sixteen bit numbers, and yet could still run a *real* operating system with *multitasking*. Given that you can put 8 megabytes in a ][+ (in 1 Meg increments), I don't think you should have any problems with a ][+ running a stripped down V7. Is anyone interested in this? If so, let me know. I know of a stripped down Unix kernal that fit in 32K on a Z-80. User applications ran in the other 32k. While this is a small amount of code, it could run a shell, ed, and other simple utilities. Apple ][+ Unix -- wait till you tell mom. Jonathan A. Chandross Internet: jac@paul.rutgers.edu UUCP: rutgers!paul.rutgers.edu!jac
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/30/89)
In article <10183@bloom-beacon.MIT.EDU> dcw@athena.mit.edu (David C. Whitney) writes: >multitasking environment on my //GS, I *know* that it can't be done within >any reasonable degree of efficiency. [followed by stuff about the Mac II PMMU] The only serious problem with multitasking the IIGS (in 16-bit mode) is that a context switch involves saving quite a bit of state, for example the direct page. The lack of memory protection is a nuisance only if tasks run amok; so long as they are well-behaved the ToolBox memory management should suffice. Remember, executables are relocated as they are loaded, into memory assigned by the centralized memory manager. That automatically takes care of the hardest part.
cdl@mplvax.EDU (Carl Lowenstein) (03/31/89)
In article <Mar.29.20.51.57.1989.28321@paul.rutgers.edu> jac@paul.rutgers.edu (J. A. Chandross) writes: >An Apple with a RocketChip (plug, plug) or a Zip Chip, or a Transwarp, etc >is a kick-ass machine compared to the early PDP-11's. The early 11's took >tens of microseconds to add 2 sixteen bit numbers, and yet could still run >a *real* operating system with *multitasking*. Not really pertinent to comp.sys.apple, but the early PDP-11's weren't quite that slow. 2.6 microseconds for a 2-operand register-to-register instructions, 1.5 for 1-operand. Plus memory access time if needed, about 1.1 microseconds for each. This is the 11/20 I am referring to. Some of the cheaper microprogrammed versions that came out after that were slower. -- carl lowenstein marine physical lab u.c. san diego {decvax|ucbvax} !ucsd!mplvax!cdl cdl@mplvax.ucsd.edu
shankar@haarlem.SRC.Honeywell.COM (Son of Knuth) (03/31/89)
In article <9949@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >The only serious problem with multitasking the IIGS (in 16-bit mode) >is that a context switch involves saving quite a bit of state, for >example the direct page. The lack of memory protection is a nuisance >only if tasks run amok; so long as they are well-behaved the ToolBox >memory management should suffice. I don't follow - I would consider context switching one of the strengths of the 65816. Basically, just change the direct page register, and forget about saving the direct page contents. Right off hand, I think the only time this would be a problem is with non-well-behaved programs, were well-behaved is defined as accessing bank 0 using only stack or direct page addressing modes (i.e. not using regular or long addressing with bank 0). --- Subash Shankar Honeywell Systems & Research Center voice: (612) 782 7558 US Snail: 3660 Technology Dr., Minneapolis, MN 55418 shankar@src.honeywell.com srcsip!shankar
Sirald@cup.portal.com (Andrew Lionel Dalrymple) (03/31/89)
On this - you might bring up the multitasking of DIVERSI-DIAL. This program handles something like 8 ports at 300baud.
brianw@microsoft.UUCP (Brian Willoughby) (03/31/89)
In article <10183@bloom-beacon.MIT.EDU>, dcw@athena.mit.edu (David C. Whitney) writes: > I think everyone here needs a bit of enlightenment. As much as I would LOVE a > multitasking environment on my //GS, I *know* that it can't be done within > any reasonable degree of efficiency. Very true, I agree, but I have a few comments to enlighten you with... > > Even Macintoshes don't have "true" multitasking (ie, Multifinder is a good > hack, but it isn't "for real"). Only Mac IIs with the PMMU installed (or any I'd settle for a "good hack" for the IIGS. > IIx - 68030) can even *hope* to do multitasking. The problem? A system for > handling virtual memory is a MUST for multitasking. Now, a virtual memory > handler *could* be written in assembler, but one running on a screeching 68030 > going at 45MHz still wouldn't go fast enough to make the machine come within > tolerable speed limits. That's why there is the PMMU - that's Paged Memory > Managment Unit. It handles page faults in hardware, so things go reasonably > fast (although most A/UX people will tell you it's still too slow). Due to the intelligent design of the 65816, hardware controlled virtual memory is actually possible. Although it works differently on the asynchronous memory interface of the 68000, a bus fault could still be handled by the 65816. All it would take is an intelligent clock generator, and some cache memory to store the virtual translation table (i.e. a PMMU816). With its single cycle memory access, you can adjust the period of the clock cycle to match the speed of the memory that the 65816 is interfaced to. This is how the GS accesses slow video RAM, and it is the same method used by the TransWarp accelerator in my II+. Each access to memory could be checked against the translation table to see where that page is stored in memory. If the page were found, then the upper address bits would be swapped to access the physical address, and if the page is not found, then the clock could be frozen until the page is properly loaded. The 65816 would never realize what happened, so you would avoid the instruction restart problems that plague the 68000 virtual memory method (sometimes a simple CPU design has its advantages!). In other words, you wouldn't have to abort and then restart the instruction later, you could just pause the CPU and let the clock run when the page is loaded. It might actually mean that you need a second processor to load the page into RAM if it is currently on disk, but considering that Apple already has a separate 6502 to handle the Desktop Bus in the IIGS that is only about 2 cm square, I think it would be easy (and price effective) to design this sort of power into a new GS! Of course, Apple probably wont do this unless they see a demand for such power in a 65816 based machine. But the problem is that there WILL BE NO DEMAND unless Apple comes out with a IIGS that shows people how powerful the new 65xxx series is! Personally, I'd love to be on the Apple design team, because I know that current technology can make the II scream. For example, the dual-port video RAM in the SE/30 would remove the restriction that requires the GS clock to change to 1 MHz for a single cycle when writing to screen memory. Why not have a powerful IIGS/8MHz (in the spirit of the SE/30) that is aimed towards those who can afford it, and lower the price of the original GS for the price concerned consumer? (the current position of the Mac Plus). These designs would open up other enhancements to speed. You could have different speeds of RAM in use at once. The virtual memory controller could place the most frequently accessed pages in static RAM addresses, with the less expensive dynamic RAM for storing less frequent data. This would help in an area that EVERY high speed processor faces: how to get RAM speeds fast enough to match CPU speed. (Someone on this net was complaining that he didn't want an 8 MHz 65816-based GS because it would require 60ns RAM. The problem is that EVERY fast CPU [don't be fooled into comparing clock speed to RAM speed] needs RAM to be that fast. That's why Compaq has a special bus on their Deskpro to allow static 32-bit RAM to be added, any normal PC RAM card would really slow down a 16 MHz or greater 80x86 machine) > > The next problem is designing a way to quickly make calls to the OS. The > Mac (more accurately, the 680x0 series), along with 80x86 machines use > something called "traps." They are basically undefined processor instructions > that can be defined by the host computer. The Mac implements its toolbox > calling by using traps. As far as I know, the 65816 doesn't have a trap > mechanism (although, I suppose the COP instruction might get useful here...). If you expand the code that gets called by the Mac OS traps, you will see several lines of assembly code which lookup the address in a BIG table and then call the proper routine based on the lower bits of the trap opcode. Only ONE trap is used, so they have to use software to access more than one OS call. Except for the method used to call this routine on the 68000 ($Axxx opcode exception trap), the 65816 could achieve the same result at the same speed. The only advantage of the method used on the Mac is that each OS call only takes 2 bytes (one opcode), while the 65816 would need 3 or 4 bytes (JSR or JSL), so what is the big problem? Most of the 65816 instructions are shorter than 68000 opcodes, so the greater size (only 1 or 2 extra bytes per call) shouldn't affect the overall code size. Another method would be to use the BREAK opcode $00 which is a software initiated interrupt and is currently not used for anything important on the II series. Each BRK could be followed by a code for the OS call needed. If you smartly used one byte for frequent calls, you could have 255 2-byte calls, with the 256th code reserved as an extension flag. > > Dave Whitney A junior in Computer Science at MIT Brian Willoughby microsoft!brianw@uunet.UU.NET or uw-beaver!microsoft!brianw or just microsoft!brianw
blume@netmbx.UUCP (Heiko Blume) (04/03/89)
>Sorry to rain on your parade, but a multitasking OS is a physical impossibility >on the // line. IT CAN'T BE DONE. Now, expend that creative energy on porting >GNU C and GNU Emacs, and I'll be VERY VERY happy! well, if you really want to see 'segmentation violation - core dumped' you're right of course but if you dont care if the thing crashes now and then it sure is possible. i.e. minix is such a beast running even on 8086 etc without mmu. of course gnu emacs is out of reach, since it is designed for 32bit virtual machines. however, (one of my favorite topics!) smalltalk-pc which was described in byte somewhere in 85 already had multitasking etc. of course it wants to be fed smalltalk programs, but what the heck, i'd LOVE it ! unfortunatley i've never found a source for it...sigh -- Heiko Blume,Seekorso 29,D-1000 Berlin 22,VOICE=(+49 30)365 55 71,BBS=()365 75 01 TELEX=184174 intro d,FAX=()882 50 65|ARPA =crash!pnet01!pro-cess!blume@nosc.mil PSI =PSI%45300043109::netmbx:blume |BITNET=pro-cess.UUCP!blume@PSUVAX1 UUCP =blume@netmbx.UUCP |INET =blume@pro-cess.cts.com
gwyn@smoke.BRL.MIL (Doug Gwyn ) (04/04/89)
In article <19611@srcsip.UUCP> shankar@haarlem.UUCP (Son of Knuth) writes: >Basically, just change the direct page register, and forget >about saving the direct page contents. Right off hand, I think the only >time this would be a problem is with non-well-behaved programs, ... Ok, I'll grant you that. Most of the large assembly-language programs I've seen for the IIGS, however, deliberately pop into 8-bit mode from time to time, and I think there might be a problem with these.
shawn@pnet51.cts.com (Shawn Stanley) (04/04/89)
dcw@athena.mit.edu (David C. Whitney) writes: >In article <8903181259.aa27052@SMOKE.BRL.MIL> SASQUATCH@ALBION.BITNET ("Kevin O. Lepard 629-5511 x6668", 517) writes: >> >>Would it be possible to write a program similar to softswitch that could >>automatically switch between applications, allowing something to run in >>background? I've heard people talk about "heartbeat" interrupts. Couldn't >>that be used somehow? Even if this cut the speed of the GS in half, it >>would still be running as fast as a normal //e > >I think everyone here needs a bit of enlightenment. As much as I would LOVE a >multitasking environment on my //GS, I *know* that it can't be done within >any reasonable degree of efficiency. > >Even Macintoshes don't have "true" multitasking (ie, Multifinder is a good >hack, but it isn't "for real"). Only Mac IIs with the PMMU installed (or any >IIx - 68030) can even *hope* to do multitasking. The problem? A system for >handling virtual memory is a MUST for multitasking. Now, a virtual memory >handler *could* be written in assembler, but one running on a screeching 68030 >going at 45MHz still wouldn't go fast enough to make the machine come within >tolerable speed limits. That's why there is the PMMU - that's Paged Memory >Managment Unit. It handles page faults in hardware, so things go reasonably >fast (although most A/UX people will tell you it's still too slow). Beg pardon, but while a MMU is desirable for multitasking, it's not absolutely necessary. The MMU keeps tasks from stepping on each others toes, and provides a large amount of data/process security, but task-switching is the main drive behind multitasking, not a MMU. (Besides, the Amiga multitasks without a MMU.) >The next problem is designing a way to quickly make calls to the OS. The >Mac (more accurately, the 680x0 series), along with 80x86 machines use >something called "traps." They are basically undefined processor instructions >that can be defined by the host computer. The Mac implements its toolbox >calling by using traps. As far as I know, the 65816 doesn't have a trap >mechanism (although, I suppose the COP instruction might get useful here...). I think what the Apple line needs is smarter I/O, maybe more hardware-oriented. It really slows the system down to have to pause on disk I/O that some other task is causing. >Apple is going to release a new system sometime that uses the 68030 (or PMMU) >to do virtual memory stuff. Sometime after that, MultiFinder will be a thing >of the past, as *real* multitasking will be here. This is relatively easy >to do on the Mac while it's remarkably hard on the //GS. So hard in fact that >nobody should even bother. I hear the Mac SE/030 is going to be A/UX capable. It's actually the design of the OS that makes it so difficult to integrate multitasking. For instance, the MultiFinder (from what I hear) does context-switching through event loops. Not particularly efficient, of course, but then the Finder/toolboxes weren't designed for multitasking to begin with. A/UX, on the other hand, was, and the programs written to run under it came into being on a multitasking system, therefore they live in it well enough. As to "nobody should even bother", please speak for yourself. Those that wish to bother should feel free to do so without being told how worthless their efforts are. I've always felt that the Apple II line is a good hobby line, and "shouldn't even bother" just doesn't fit into that universe too well. >Sorry to rain on your parade, but a multitasking OS is a physical impossibility >on the // line. IT CAN'T BE DONE. Now, expend that creative energy on porting >GNU C and GNU Emacs, and I'll be VERY VERY happy! It's only a physical impossibility without interrupts. Your statement that IT CAN'T BE DONE just shows that you don't know enough to accomplish it yourself, or you're not willing to put the effort into even thinking about how to accomplish it. Right now, I can envision methods for accomplishing it. For instance, if someone wanted to write a shell, and then write programs that would be shell-aware, and the shell had multitasking abilities, there you go. As is true with most multitasking systems, the software that runs under it is generally designed to run under it (with I/O handing, etc.), so that's an obstacle to overcome to be sure. I'm not saying that all Apple II software should be converted to some multitasking shell. I am saying that it would be fun to do something like that. Again, in my opinion, it's a hobby machine, and that to me means that there are no absolute rules with regard to what you can and can't do. (Beyond the obvious. And the absence of a MMU is not one of those.) UUCP: {uunet!rosevax, amdahl!bungia, chinet, killer}!orbit!pnet51!shawn INET: shawn@pnet51.cts.com
MEK4_LTD@DB2.CC.ROCHESTER.EDU (04/04/89)
I am wondering about multi-tasking on the IIGS. I have heard that it can't be done because the there is no MMU in the GS. Can't you write a software implemented MMU? It would seem that it could be possible for multi-tasking programs as long as they requested all their memory, and the MMU was "running in the background" to handle virtual memory. Would this be too slow? Would interupts mess this up? Or would you need an interrupt evertime the applications accessed mem locations? Mark Kern MEK4_LTD@db2.cc.rochester.edu
ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre) (04/06/89)
In article <9949@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <10183@bloom-beacon.MIT.EDU> dcw@athena.mit.edu (David C. Whitney) writes: >>multitasking environment on my //GS, I *know* that it can't be done within >>any reasonable degree of efficiency. >[followed by stuff about the Mac II PMMU] > >The only serious problem with multitasking the IIGS (in 16-bit mode) >is that a context switch involves saving quite a bit of state, for >example the direct page. I thought the 65816 would allow you could change the direct page pointer. If so, then you don't need to save stuff, just have your interrupt handler create/switch to a new one for the next task. I know that the '816 stack pointer is changeable, so you don't have to worry about stack management if you don't want to. On the //e, you can change memory spaces with bank-switching, so you can avoid the problem here as well. For a Unix clone on the GS, my understanding of Unix philosophy suggests that none of the applications need to be > 64K anyway, so 8-bit mode should mostly suffice. disclaimer: I could be wrong. -- - Ralph W. Hyre, Jr. Internet: ralphw@{ius{3,2,1}.,}cs.cmu.edu Phone:(412) CMU-BUGS Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA "You can do what you want with my computer, but leave me alone!8-)" --
blochowi@cat28.CS.WISC.EDU (Jason Blochowiak) (04/07/89)
As I understand it, a MMU monitors what addresses are accessed by the CPU - this way, each process has a set of boundaries as to what memory it can access, so if it tries to write to some other process' memory, the MMU prevents it (and flags it in some way). Because of this, even if one (user - I'll explain this in a bit) process goes haywire, it won't screw up other processes. This makes a multitasking system more reliable. Also, on some processors (e.g. The 68000 - I'm not familiar with bunches of other processors), there are separate "user" and "supervisor" (or "system") modes - this makes it possible to protect some memory locations from being toasted by a user (non Operating System) program, so that a user program can die without screwing the system up (basically a limited form of what the MMU does). Anyways, if a system process (part of the operating system) makes a mistake (and I've yet to see an OS without bugs), the whole machine can go crashing down (if the mistake is large enough). Getting back to the //gs - it has no MMU, so there's no way to guarantee that one process isn't writing to some other process' memory space. What you were talking about (simulating a MMU in software) is possible, but not practical, and, unless I'm missing something, probably not terribly useful. The most straightforward way of doing it would be to have something that runs perodically which verifies memory belonging to a particular process. So, while process #1 is running, the verifier checks to see if the memory belonging to processes #2 and #3 gets changed, and while process #2 is running, the verifier checks to see if the memory belonging to processes #1 and #3 gets changed. Same goes for when #3 runs (assuming there are only 3 processes going). Now for the problems: Doing the checking in a reasonable amount of time would be REAL tricky - either one does it by chunks, or one does it by checking the whole thing at a time. The first option (chunks) would take awhile before a violation would be noticed (a violation is a situation in which one process writes into the memory of another), kind of missing the point of the whole thing. Checking the whole thing at once would take gobs of time (inefficiency to the point of uselessness). And then, on top of that, violations would be detectable, but not preventable, which would mean that the system wouldn't be much more reliable than it was without the verifier... This does not mean that multitasking is not possible on a //gs - this means that SECURE multitasking is not possible with the //gs the way it is. Short answer: Good idea, but I don't think it'd work. Jason. p.s. This is terrific, both my recent messages were negative - oh, well, I hope they've been of some use to someone out there... ------------------------------------------------------------------------------ Jason Blochowiak (blochowi@garfield.cs.wisc.edu) "Not your average iconoclast..." ------------------------------------------------------------------------------