Hi!
18-Июл-2004 20:33 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:
EA> Hi, I think it is now clear that Turbo C 2 cannot optimize for 386.
EA> HOWEVER, the NASM parts can still be optimized for 386. So instead
First, in *.asm files for 386 currently present only registers saving
and restoring, so no usefule gain will be achieved. Second, you can't
compile NASM with XCPU=386 and .c files without this - at least, this brokes
inthndlr.c:int2F_12_handler() (see definition for struct int2f12 above it).
EA> of generating an error message when you try to create a 386 kernel
EA> with TC2, I suggest displaying only a warning message and let at
EA> least the NASM parts be 386ish.
I think, making error message about unsupported option is enough.
Though, if there will be requests, into tc.mak may be added generating error
if XCPU > 186.
EA> This reminds me that the non-resident part of the kernel should, if
EA> possible, show an error message if you try to run it on an incompatible CPU.
Write this into bugzilla "request for feature" (RFF). :) But I doubt
this will be implemented, because requires additional code to detect CPU
type (and there is no proven code, which can't be broken by some not
completely compatible CPU).
EA> By the way, I recently saw something about 32bit and 64bit multiply / divide
EA> code... where is it used?
I not see what you saw about 64bit muldiv, but there are no such beast.
EA> Bonus WISH for "all-time enabled debugging code": Please add
EA> - a register dump for the invalid opcode handler (now often only a small
EA> part of the stack dump reveals useful information).
Stack already dumped int INT6 handler.
EA> If naming the registers
EA> takes too much effort, you can instead use "pusha" (or 8086 equivalent for
EA> 8086 kernels) right before doing the stack dump. That will mean only VERY
EA> small increase in code size.
...but may overwrite some more memory areas (and handler itself). In
any case, write this into bugzilla as RFF.
EA> - the caller IP should be displayed for "too many near fnodes" panic message.
EA> It is very hard to find the reason of the panic otherwise.
Probably, panic() also should dump stack and registers.
PS: Some smart guy offers to make right-left dump, because this eases to
extract numbers on Intel platform (low digits placed first), whereas we use
Fibonacci method to write number (high digits first). Thus:
xxxx:xx00 01 ff f1 07 00 ... chars...
xxxx:xx10 ...
will look:
... 00 07 f1 ff 01 xxxx:xx00 chars...
... xxxx:xx10 ...
And there easier to see dword number "07F1_FF01" or word "F1FF".
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
