Hi!
20-Июл-2004 00:55 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
BO> encouraging... In any case, I appreciate that a bug was found in
BO> ludivmul.inc; the same bug was in fact present in the 64 bit version I
BO> adapted it from! Well I notified the original author.
BTW, may you point me place, where I may see the prove that present
algo is correct? I myself prove this, but my prove not looks beauty to
include into comments as explanation. :(
BO> What I don't like is that the fix from Arkady (for the 1000th time...)
BO> does 3 things at the same time -- formatting, fixing, and optimizing.
:( ludivmul.inc is a complete, self-contained, independed, small
module, and if I completely rework it (fix bugs, optimize code, add more
comments to explain algo and, yes, improve formatting to make code more
readable and understandable) - what bad in this?! Especially interface not
changed (and can't, of course).
It is a pitty that you returns with critics. :(
BO> This makes it impossible to see where things are really fixed.
It not "fixed", it reworked! Differ these things. Fix is only bonus of
new control flow.
BO> So I can make a deal, you isolate your bug fixes and I'll return and be
BO> friendly, or you don't and I'll simply disappear. It's that easy.
My bugfix-list for umb_init() includes 7 positions. How I may "isolate"
bugfixes from new umb_init() edition?!
BO> Essentially for Turbo C the compiler helpers are extracted from the c
BO> compiler RTL to be absolutely sure we only link those and nothing else from
BO> that library. These are automatically linked and called "far", which is
BO> correct because init_text and _text are in different segments. This is why
BO> those routines have to have a fixed segment and that's only easily
BO> accomplished in low RAM.
I have the trouble: when I move _TEXT after HMA_TEXT and include into
TGROUP (to minimize usage of low memory), BC's kernel behaves wrongly. Do
you mean, that joining _TEXT with HMA_TEXT causes BC to generate near calls
to far routines? Hm. I should try: what happen if (for non-Watcom) move
_TEXT after HMA_TEXT_END and define for it new group (say, TGROUP2)?
BO> When Tom and I ported the kernel to Watcom we stumbled upon the problem
BO> that U4D was called "near", where it had to be called "far".
BO> Tom even filed an Open Watcom bug for that one, see
BO> http://bugzilla.openwatcom.org/show_bug.cgi?id=193
Later I look at this. But definitely, this was should be commented
somewhere (in sources). :(
-------------------------------------------------------
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
