Aitor Santamar�a Merino wrote:
I can't answer anything emm386 specific, but maybe this'll help a little until Michael/Tom/? answers.
Hi there,
I have started reading EMM386.ASM (not the latest "hot" version, but the
...
(2) What is the meaning of this structure? How much memory does it weight actually, or how does the assembler determine that? (the bit that I ignore is the (?))
RES_STACK SEGMENT PARA USE16
DB V86_TOS DUP (?)
RES_STACK ENDS
V86_TOS EQU 200H ; Size of monitor stack
This creates an unitialized segment of 0x200 bytes, and so may not occupy space in the executable image on disk. The 'dup (?)' is similar to resb in NASM and in this case it is created in its own segment instead of the data (or code) segment. I believe NASM does not support ?, it simply means uninitialized (often 0 but should not be assumed as such).
It appears to be the stack segment of the initial real mode chunk of code, and only used at start up and in some cases on return to real mode; but this is just a guess from the comments.
(3) Why do several ASM labels begin with @@? For example: @@UMBloop @@UMBnext do those @@ have any meaning?
@@ means local label, like . in NASM/FASM
(4) What are those special comments/marks for? What are they indicating? They are all over the sources
; (*-9-*)
; (#-9-#)
these appear to be some form of revision control markers to indicate ?changes/features? that occurred in newer versions.
(5) In the startup of the driver, it is set 00AAh into memory 0040h:0072h, but I can't find references to this BIOS variable, what is that?
not sure
(6) Finally, a simple and un-intentioned question about TASM/NASM. Is it feasible that EMM386 be ported to NASM?
I mean, of course the answer could be YES, but it is worthless, but I just want to determine wether there is any actual problem, or it is just that it is a lot of work for little gain.
I seem to remember Tom saying it was not feasible, but so was VCPI, so I am afraid I mis-interpretated your comment, Tom.
I think its a matter of not worth the gain; there is the initial work to change to NASM compatible syntax (a lot of work) and then there is the fixing the introduced bugs. The end result is a binary that does the same thing and probably has the same people working on it. There are also probably syntatic assistance in TASM/MASM that makes the code easier to write/read that while can be replicated in NASM, it may be more work (even if this just means learning how NASM does it). The driver appears to take advantage of MAST/TASM segment ordering (the .SEQ indicates the the linked code should included the segments in order encountered (sequentially), then each segment is listed, and later added to with actual data [see segment grouping in MASM help]. Other than MASM/TASM syntax and use of macros, I don't see any other major issues preventing a port, but again it doesn't appear to be something worth the work and not being too familiar I could be overlooking something subtle.
More questions coming when I finish reading the sources.
Thanks in advance, Aitor
Jeremy
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
