On Thu, May 7, 2009 at 2:57 PM, Christian Masloch <[email protected]> wrote: > Hi, > > I just looked at the recent SVN commits to fix that CALL 5 stuff. The new > commentary about it contains some errors. I'm appending the things I would > improve about it. It's not meant to annoy you, although I imagine it > could. (Does it?) > > Regards, > Christian
I'm glad you are reviewing and commenting on them. > > --- > This comment was put into the PSP structure in one of the header files: > > /* offsets 5-9 are a far call to absolute address 0:000Ch > coded so that CP/M apps can do a near call to psp:5, does a > far call but ensures word at offset 6 is size of COM file > e.g. FEF0h by using 1MB wrap around address 0F01D:FEF0 > (jmp code stored at 0:000C should be duplicated in HMA FFFF:00D0) > Note: MS-DOS has value as FEEE which wraps to 0:00BEh */ > > The address of 0:000Ch is wrong and should read 0000:00C0h. (It might be good catch, that was a typo > interesting that this is where interrupt vectors 30h and 31h should be > stored, and this is the reason these interrupts can't be used/called in see below > DOS.) The word at offset 6 is usually not the exact size of the first > segment, because at least the low nibble is fixed to zero. It does not > depend on the size of the .COM file. If pointing out that a duplicate is agreed not the most unambiguous description, I was trying to be brief but still indicate that the address does not use a normalized form on purpose; I was thinking allocated memory size not disk size but I see how that is confusing as worded > stored in the HMA, it might be interesting why this is done: to catch > "call 5"s while the A20 line is on. an implicit assumption on my part that this was understood :-) > > The note seems not really correct, as mentioned in RBIL (Int21.26, PSP > description) this is a bug of MS-DOS's DEBUG program (not duplicated by FD > DEBUG as far as I know). Might be that RBIL is wrong with that however. Is > it? ok, I attributed the incorrect address to the wrong program, removing as unneccessary comment > > --- > This comment was put into entry.asm: > > ; For CP/M compatibility allow a program to invoke any DOS API function > ; between 0 and 24h by doing a near call to psp:0005h which embeds a far > call > ; to absolute address 0:00C0h (int vector 30h & 31h) or FFFF:00D0 (hma). > ; Note: int 31h is also used for DPMI > ; Upon entry the stack has a near return offset (desired return address) > and > ; far return seg:offset (useless return to data at offset 0ah after far > call > ; in psp). We convert it to a normal call and correct the stack to appear > same > ; as if invoked via an int 21h call including proper return address. > > The note is inappropriate (or incomplete) because DPMI explicitely uses > Int31 only in Protected Mode, and therefore only modifies the Protected > Mode IVT's entry 31h. It might be noted that not the complete return data extended comment to include this is for protected mode, the goal of this statement is to indicate the multiple use of these memory locations > is useless, only the ip (offset) value. (Unless you assume cs = current > PSP, which the code doesn't.) that is a miss reading, I don't mean the return address is data that is useless, I mean the code returns to data (not code) which is a useless thing to do :-) rewording > > --- > Might be just my conclusion, but won't it be better to document this just > in one file? Then you could as well add a short notice to the header file, > pointing to entry.asm (or the other way around, I just personally prefer no, the comments are for different purposes the ones in process.h are meant to document the PSP and information about the data it contains, whereas the comments in entry.asm are meant to document how the CP/M call works and the algorithm the kernel uses to handle it. the comments necessarily overlap since the data structure is used by the implementation note: there is also a related comment in the COM loading routine in task.c > NASM style "%if 0" comments over C's star-and-slash constructs, and > usually write such extensive commentary into source rather than header I prefer comments in both, the data structures should be commented to explain their usage [values, etc] and the implemenation should explain itself which requires comments in both files - however I do agree that duplication should be avoided where possible > files). Some correct information (like the Int30 & Int31 notice, and > (incomplete) mention of DPMI) was present in one of the files but not in > the other one. this was on purpose as I, perhaps unsuccessfully, was trying to explain different aspects while keeping duplication of information to a minimal > > --- Jeremy ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Freedos-kernel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
