Eric, My Thanks for your "support" of what you all call "pipelining" (I call it simultaneous I-O) in our discussions with Bernd, in your earlier post today.
>> No one is suggesting an API only for MEM! Also, my ideas about new >> XMS commands are only for 64-GB memory, NOT for current XMS commands > > Ah okay... So there would be a separate API, and separate > memory areas for XMS 2/3 and the new API then? Absolutely! Forgetting XMS V2.0 (only 64-MB), I am suggesting that all XMS V3.0 requests for 4-GB remain as-is, using the first 4-GB of memory. XMS "V4.0" commands, if we choose to call them so, will be modified 3.0 commands to deal with memory ABOVE the first 4-GB. >> ... "Protected mode" moves are done by JEMM386/JEMMEX, since on >> systems that use either driver, only THEY can "trap" and execute >> an "Int 15h AH=87h" move-memory request! > > True - if you have a HIMEMXXL then it will need a way to > communicate with some EMM386 if you want to use both in > parallel. On the other hand, if the access to XMS style > memory beyond 4 GB is implemented in some JEMMEXXL then > it would only have to communicate with itself, as it is > both HIMEM and EMM386 inside the same driver already. If we do an XMS "V4.0" upgrade for 64-GB memory, the "scheme" used by "real mode" and "protected mode" should be consistent for both. This is why I suggest any XMS requests using 64-GB memory address- ing (allocates/locks/moves etc.) must include the "page" number. >> if a driver were to request 64-GB memory BEFORE loading JEMM386 > > Loading drivers BETWEEN HIMEMX and JEMM386 is a somehow > unusual case if my opinion. "IN" your opinion, but in fact I agree with you on this point. >>> In theory, you can allocate a lot of RAM in pieces of 16 MB. >> >> This requires revision of many programs, which are NOT expecting > > True true, yet Windows 3 was so widespread that many drivers > actually do contain workarounds for Win compat ... Still a BIG problem for drivers like UIDE wanting gigabytes of memory. XMS drivers provide at most 128 "handles", and your idea of 16-MB each would take ALL those handles, leaving none for other drivers/programs. > At least in Linux and Windows, a pipeline is something provided by > the OS kernel ... But we are NOT Linux/Windows, are we?? >> UIDE could still have its cache in 64-GB memory if it were changed >> to do all I-O through its "local" 128-KB XMS buffer. That buffer >> would have to stay in 32-bit address space, as SATA/UltraDMA chips >> were designed in the 1994 "32-bit days". > > Interesting. One would assume that SATA/UDMA was more future-proof > than that ;-) Maybe newer controllers can access more than 32 bits of I-O bus, but I am not "holding my breath", and UIDE must still run OLDER controllers! >> Doing all I-O thru its buffer costs a small amount of time in UIDE. >> But if a HUGE cache is needed and a fast-enough CPU for its binary >> searches is present this COULD be made to work > > Yes and no - the metadata of the cache could be kept in the > easily accessible area while the data itself can be copied > with normal XMS driver calls without extra performance loss, > allowing the cache data to stay in non-lockable extra large > XMS above the 4 GB boundary. Of course I wonder why you do > want a cache of 4 GB instead of just using a RAMDISK...? Agreed -- UIDE's cache tables and binary-search table could remain in normal 4-GB memory, along with its "local" 128K XMS buffer (64K data, and 64K for UltraDMA "alignment"). Re: caches and RAMdisks, a cache handles dynamically-changing disk data sectors, via LBA addresses and normally a first-in first-out algorithm. A RAMdisk handles a more permanent set of logical FILES, using a normal DOS directory. Users who want SPECIFIC files always available will want a RAMdisk. Those who want to speed-up "general" sector handling to/from disks will want a cache. Those who want a SCREAMING-fast DOS system will want BOTH! >> I agree -- I ran Win/NT with only 256KB memory for over 10 years, > > 256 MB, probably :-) Wait until YOU are age 63, my friend, and "typos" are a fact of YOUR life, as well! ;) > I remember that life was quite okay with 16, 32, 64, 192 MB > on mixed versions of Windows and Linux for many years indeed. Now you understand my quite-SERIOUS comments about "Do we really NEED all this??" I still say a GOOD 4-GB DOS system can do LOTS of work! > Note: Bernd cannot program anything but Warcraft and BAT afair :-) Be kind -- Bernd contributes much to DOS/FreeDOS/etc. same as we do. >> I would rather NOT be "unsafe" and prefer to "lock" any XMS used >> by a SYSTEM driver AGAINST being re-mapped, moved-around... > > I know I know. My cache also locks memory because it feels bad > to have the data of a disk cache swapped out to a disk... :-p. > That probably also holds for UIDE, now that I think of it... ABBBB-solutely!! >> If XMS "locks" are unusable when running Win/3, maybe it is best >> not to support Win/3... > > No, you just cannot create locks on NEW handles, such which > got allocated after Windows took over memory maintenance. Then I hope UIDE/RDISK or other large-memory drivers DO load first! > Enjoy working on your miracles :-) Thanks, and you on yours ;-) Jack R. Ellis ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
