Matthew Montchalin asked: >On 31 Oct 2002, Michael J. Mahon wrote: >|>Can you be more explicit? If ror
involves a read of a >|>specified memory address, and then rotate some internal register >|>+carry, before write-back, are you suggesting that it makes no >|>difference how far into the execution we go, if the abort occurs >|>prior to the write-back, the whole instruction is executed over >|>again, after we get back from the Abort handler? >| >|I said on the _first_ reference to the memory address. So the >|abort would be asserted when the location was read, and before >|any data was returned. > >What about memory mapped I/O? > >|If the memory is not present, there can be no valid data. The >|important part is that no internal register is updated by the >|aborted instruction, so that it can be re-executed later. For a virtual memory implementation, memory-mapped I/O would normally always be mapped, and so not subject to abort. However, since a virtual memory system maps all process addresses, including those associated with I/O, it would be possible to implement a virtual memory-mapped I/O system, in which the actual mapping to a device could be done only if the process has the "rights" to access the device--just as with data pages. Again, since the unmapped condition is detected without any access to real address space, the instruction can be aborted and transparently re-executed when the mapping has been made. There are a number of systems that use virtual memory- mapped I/O, because the OS's protection mechanism can be enforced by the normal page table lookup. -michael Check out 8-bit Apple sound that will amaze you on my Home page: http://members.aol.com/MJMahon/ Roy replied: >Michael J. Mahon wrote: >> Matthew Montchalin replied: >> >> >>>On 31 Oct 2002, Michael J. Mahon wrote: >>>|>I've heard conflicting information about just what happens when the >>>|>Abort pin is pulled low. Is it true that it wipes out the instruction >>>|>currently being executed? Someone told me that it tries to 'resume' >>>|>the instruction when you finally RTI and get out of the Abort handler. >>>|>Obviously a ROR instruction, if interrupted in the >>>|>middle of the rotation, is going to result in something odd after >>>|>the processor resumes from the Abort. >>>| >>>|The intent is that it cancels the effect of the in-process instruction, >>>|and it should work if asserted during the first memory-access >>>|cycle of an instruction. >>> >>>Can you be more explicit? If ror
involves a read of a >>>specified memory address, and then rotate some internal register >>>+carry, before write-back, are you suggesting that it makes no >>>difference how far into the execution we go, if the abort occurs >>>prior to the write-back, the whole instruction is executed over >>>again, after we get back from the Abort handler? >> >> >> I said on the _first_ reference to the memory address. So the >> abort would be asserted when the location was read, and before >> any data was returned. >> >> If the memory is not present, there can be no valid data. The >> important part is that no internal register is updated by the >> aborted instruction, so that it can be re-executed later. >> >> >>>|This is consistent with it's intended use for a virtual memory >>>|implementation, >>> >>>I was just thinking it would be more useful for implementing >>>a copy-protecting mechanism to be used in conjunction with >>>copy-protected software. >> >> >> I don't know what you're thinking about here. NMI should do >> a fine job of interrupting a program (after the conclusion of the >> currently-executing instruction). >> >> >>>|where it would be used to interrupt & cancel the current instruction >>>|if it referred to un-mapped memory--a page fault. >>>| >>>|After the page has been made present by an interrupt service >>>|routine, >>> >>>Sure, the Abort handler itself would have to save stuff to disk, >>>bring something else in from disk, and then restore registers >>>and RTI. >>> >>>|the program would be resumed at the aborted instruction >>>|so that it could re-execute to completion. >>> >>>Hmmmmmmm.... Okay. >> >> >> This is the way that all modern data page-fault handling works. >> >> Some older machines, because of their instruction semantics, >> needed to pre-check data presence before starting execution of >> an instruction, because changes were made to memory prior to >> a possible data page fault--for example, a page-crossing move >> that could not be re-started in the middle of the move. > >This is a bit over my head, so if I'm off, don't hesitate to correct me, >but, it seems to me that what you are saying is that, via a virtual >memory scheme, a IIgs could have much more than 16 megs of RAM >installed, switching banks in and out of the memory space, not too >dissimiliar to the old LIM EMS scheme on PCs. Have I got that right? Virtual memory is more than bank-switched physical memory. The usual implementation of virtual memory is to allow a processor with a large virtual address space to operate with significantly less physical memory, with the non-resident "memory" located on disk. This is most useful when there are multiple processes running, so that another active process can be running while a page fault for the faulting task is being serviced. In this implementation, the purpose of virtual memory is to permit a large address space to be simulated by a smaller physical memory. It can only work if the "active" pages of the program are substantially less than the "total" pages in its address space, so that the "working set" will fit into the available physical memory. A virtual memory scheme can also support more total memory space than the processor can simultaneously address. In such an approach, the processor's effective addresses are extended by, for example, a process id, which is then mapped into the physical memory through page tables. This is a "segmented" virtual memory, since the high order virtual address bits do not participate in the processor's effective address calculations. In both schemes, it is common to associate interprocess access permissions with the page table, allowing "protected" multi- programming and controlled interprocess communication. It sounds like you are thinking more of the second scheme, to permit more real memory to be used than the processor can directly address. In this scheme, the physical memory may be much greater than the processor's address space (16MB), and paging to disk may be a non-issue. Unfortunately, no individual program could see more memory space than what the processor can currently address, since all existing applications operate within the processor's address space limits. To use more address space than this would require application changes, akin to explicit bank switching, since the processors effective address calculations extend only to its native address space. The primary value of applying this approach to the IIgs would be to permit it to multiprogram multiple applications. Although this would be interesting, the relatively low performance of the IIgs processor generally requires dedicating it to a single task at a time, and there are no popular multiprogramming environments for the IIgs (GNO is pretty much a niche OS). A virtual memory system involves some pretty specialized hardware support (the address translation hardware), plus an OS which handles the setup of that hardware and the page and protection faults which it detects. It seems unlikely that anyone would invest the design and implementation time to create these for the IIgs at this point. -michael Check out 8-bit Apple sound that will amaze you on my Home page: http://members.aol.com/MJMahon/ Roy wrote: >Michael J. Mahon wrote: >> Roy replied: >> A virtual memory scheme can also support more total memory >> space than the processor can simultaneously address. In such >> an approach, the processor's effective addresses are extended by, >> for example, a process id, which is then mapped into the physical >> memory through page tables. This is a "segmented" virtual >> memory, since the high order virtual address bits do not participate >> in the processor's effective address calculations. >> >> In both schemes, it is common to associate interprocess access >> permissions with the page table, allowing "protected" multi- >> programming and controlled interprocess communication. >> >> It sounds like you are thinking more of the second scheme, > >Exactly. > >to >> permit more real memory to be used than the processor can >> directly address. In this scheme, the physical memory may be >> much greater than the processor's address space (16MB), and >> paging to disk may be a non-issue. > >The LIM EMS specs 3.2 and 4.0 did this, allowing (under 3.2) an 8086 to >address 8 megs of RAM (4.0 was more, but I can't remember how much more Strictly speaking, it didn't increase the amount of memory that the 8086 could _simultaneously_ address, but simply standardized a bank switching scheme--much like RamWorks did for the Apple II. At an application level, if data memory was always accessed using certain standardized library routines, then it created the software abstraction of a larger virtual address space (like Lissners storage access routines in AppleWorks). But such a scheme does not support all the standard memory reference instructions of the host processor--usually only load byte/word and store byte/word. Alternatively, it may support the idea of copying or bank-switching a software selected region of memory into one or more "windows", where up to a "window-full" can be accessed with full generality (but any pointers outside the "window" will need to be handled interpretively by the storage manager). >- it also allowed multitasking with the programs and data in the EMS >space.) Both specs used a 64K bank in the upper one third of the 8086 >address space as the "window" to the EMS space, allowing a program to >move data into and out of the EMS space (the "L" was Lotus, as some 123 >spreadsheets were so large they couldn't fit into the 640K of a PC's >user's space, and, since "A-DOS" wasn't around yet, Lotus' customers >needed a way to have the future then), as well as moving not just data >but program code: overlays, and sometimes whole programs into and out of >the DOS space (task switching - WordPerfect's "Library" [later named >"Office" before any "Suites" were ever sold] would move WP's WP, >spreadsheet, database, and accessory programs like calculator and >calendar in and out with their data in a task switching mode.) Yes, these were all handled very much like AppleWorks handles its extended memory through its storage manager. >> Unfortunately, no individual program could see more memory >> space than what the processor can currently address, since >> all existing applications operate within the processor's address >> space limits. To use more address space than this would >> require application changes, akin to explicit bank switching, >> since the processors effective address calculations extend >> only to its native address space. The primary value of applying >> this approach to the IIgs would be to permit it to multiprogram >> multiple applications. >> >> Although this would be interesting, the relatively low performance >> of the IIgs processor generally requires dedicating it to a single >> task at a time, > >Which is why a task switching scheme would make more sense than a >multitasking one. Of course, currently, how many IIgs programs can one >fit into the 8 megs of memory space? If I had the entire Spectrum >Internet Suite loaded, could I also have AppleWorks GS fit in memory at >the same time? Can anyone conceive of loading all the programs they >might really want to be using, and have 8 megs not be enough RAM? And since each of these applications could use more memory in some circumstances, do they contain the logic to request more memory after they have been started? I suspect not, since the concept of using only as much memory as you need, and requesting more as the need grows, is a concept that comes from multiprogramming, where it is assumed that some other task can make good use of what you are not using. >and there are no popular multiprogramming >> environments for the IIgs (GNO is pretty much a niche OS). >> >> A virtual memory system involves some pretty specialized >> hardware support (the address translation hardware), > >That's why EMS cards weren't cheap. If done on the IIgs, I would imagine >that the "window" would need to be loaded in the 8 meg ROM space. I expect that the IIgs wouldn't work if writes were done to this space. The windows would have to come out of normal RAM space. EMS cards were software-controlled explicit bank-switching devices, so they only required selective re-mapping of a few high- order address bits. This would not have been very expensive. On the other hand, the large number of DRAMs on the card would account for most of its cost. The virtual memory support on a processor chip (TLB, etc.) is a small, specialized associative memory. Though it is specialized, it does not occupy a large fraction of the chip (5% might be typical), and so is not a primary cost determinant. For many years, the 80386 had an on-chip TLB that went virtually (!) unused by any Microsoft OS. It's a lot cheaper (and faster) to build it in than to add it on externally, as was done with the 680x0 Macs when virtual memory was introduced. >plus an >> OS which handles the setup of that hardware and the page >> and protection faults which it detects. > >For the PC, the EMS drivers took care of that. I would think that such >would also be the case with GS/OS. But it certainly wouldn't be a >trivial programming job. The only way to make it truly like virtual memory would be to find a way to reference all the memory you could ever wish for (probably more than the 8MB supported by the IIgs hardware) and have the processor be interrupted on any access to non-mapped memory, but allowed to proceed at full speed if the memory were already mapped. This would necessitate a larger-than-24-bit effective address in the 65816 and (since we're postulating a processor which does not currently exist) a built-in TLB to efficiently handle the mapping and interrupt when mapping fails. Alternatively, the 65816 and IIgs could be left alone, and external mapping hardware could support up to 8MB per application, for several concurrently loaded applications. This would also require that the OS manage the mapping hardware upon task switch. The latter is more easily done, but would offer a smaller set of advantages. >It seems unlikely that >> anyone would invest the design and implementation time to >> create these for the IIgs at this point. > >I think that's a realistic assessment. I was just asking "in theory." >Thanks Michael. It's interesting to consider "alternate realities". ;-) -michael Check out 8-bit Apple sound that will amaze you on my Home page: http://members.aol.com/MJMahon/