Hi!
4-Янв-2005 01:00 [EMAIL PROTECTED] (Aitor Santamarэa Merino) wrote to
[email protected]:
ASM> (1) This one is easy:
ASM> .486p
ASM> Does this mean to use 486-specific instructions (that is, not to
ASM> complain if one comes across 486-specific instructions)?
This one just _enables_ usage of protected mode ("p" suffix)
instructions of 486 (and all below) CPUs.
ASM> What happens in that case if I have a pure 386?
Nothing wrong, unless you use in your source some 486-specific
instruction and try to execute it on 386.
Note: cpu-type directives doesn't change source, they just _enable_
usage of cpu-specific instructions in your source. For example, without .386
I can't use 32-bit instructions in my source.
ASM> (2) In the "XMS" handler:
ASM> global_disable_a20:
ASM> local_disable_a20:
ASM> mov ax,1
ASM> mov bl,0
ASM> retf
ASM> (btw, what about xor bl,bl to save a memory transfer?)
This _not_ saves memory transfer: both instructions are 2-bytes in size
and on all 186+ CPUs use same amount ot ticks. On the other side, `xor'
modifies flags.
ASM> Now one more future wishes question: I guess that after Michael's
ASM> excellent work through VCPI and VDS, the next remaining big todo for EMM
ASM> is to have XMS/EMS shared memory pools, does it mean that EMM's XMS
ASM> manager is enlarged to XMS functions
I suggest, that there _may be_ useful to duplicate HIMEM functionality
in EMM386, so EMM386 may work even if HIMEM isn't loaded. At least, this
allows to faster add support for common memory pool (if will be used
built-in himem).
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
