brad@looking.UUCP (10/18/87)
Is there some official place to mail comments on the new LIM EMS 4.0 spec? Here are some. While I realize the spec was mostly an effort to integrate the old EMS with EEMS, and to provide specifications for features that Operating Systems could use, I feel it didn't leave much for the future. One thing that's a real problem for some applications is speed. To bank switch, you need an INT, which might do all sorts of things, including page to disk in a software emulator. Fact is that with most boards, a bank switch is just one or two OUT instructions. Quite fast. Yet because the of slowness of the interface, applications like 1-2-3 keep their own internal tables about what banks they have in ram, which banks are least recently used etc. They execute far more code figuring out whether they should bank switch then almost all the hardware requires to *do* a bank switch. The answer is to put a special function into the EMS spec. This function would be called "place map page code into buffer". This function would place the code to do a bank switch, followed by a RETF instruction, into a code buffer provided by the user. There would have to be three sub-functions. 1) Get size of code buffer required 2) Place switch code into buffer 3) Query speed advantage of new code. Number 3 is there for a special reason. Because this function would have to work with all sorts of EMS drivers, it's likely that some drivers won't be able to copy a fast bank switcher into the buffer. Differing processors and protection levels may also prohibit this. That's OK, because any driver can simply copy an old-style INT interface call into the buffer. This will always work, but it might be worthless. A "speed advantage" number would tell the application whether to use the code or not. Smart applications would have two kinds of EMS access code. The kind with the bank maps and LRU tables, and the raw access kind. If the speed advantage were good, they would switch to the raw access method. Dumb software can use just one method, and run the risk of being slow with drivers that are slow at bank switching. Anybody serious about EMS will have hardware bank switching, and so the many applications would be able to run at blinding speed in comparison to what they do now. I can easily guarantee a 3:1 speed improvement on something I'm working on now. --------------------- 2) Instead of telling the location of the physical page array to the application, and giving bank numbers, I think it would be a lot smarter to think about returning segment register values instead. Applications could then be written that would run in protected mode or real mode. They would get back a segment register and use it. In real mode, it would be the segment of a switched in bank. In protected mode, it would be a live 286 segment, somewhere in the much larger address space. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473