Hi Arkady and others,
I'm still not sure if and when I really return, the archives aren't really
encouraging... In any case, I appreciate that a bug was found in
ludivmul.inc; the same bug was in fact present in the 64 bit version I
adapted it from! Well I notified the original author.
What I don't like is that the fix from Arkady (for the 1000th time...)
does 3 things at the same time -- formatting, fixing, and optimizing.
This makes it impossible to see where things are really fixed. See the
following is enough:
--- ludivmul.inc.~1.2.~ Sun Jan 27 14:13:07 2002
+++ ludivmul.inc Tue Jul 20 00:35:31 2004
@@ -88,10 +88,12 @@
pop bx ; get dividend lo-word
mov cx, ax ; save quotient
mul di ; quotient * divisor hi-word (low only)
+ push di ; save divisor hi-word
xchg ax, di ; save in di
mov ax, cx ; ax=quotient
mul si ; quotient * divisor lo-word
add dx, di ; dx:ax = quotient * divisor
+ pop di ; restore divisor hi-word
sub bx, ax ; dividend-lo - (quot.*divisor)-lo
mov ax, cx ; get quotient
pop cx ; restore dividend hi-word
I'm sorry but I simply don't have the time to go through all the other
patches. If they were reduced to just bug fixes I'll promise that I'll
have another look though -- I still monitor the mailing list every now and
then. Guys *any* project that wants to be close to a 1.0 release must be
in deep freeze, a stabilation, that means that we should really freeze the
mainline kernel for anything but bug fixes. No optimizations, no
reformatting, no new fancy macros, no nothing but bug fixes with the
minimal amount of lines changed. Of course feel free to have your own
branch, but I don't think it's in the interest of the project to
use that for a 1.0.
So I can make a deal, you isolate your bug fixes and I'll return and be
friendly, or you don't and I'll simply disappear. It's that easy.
It looks from Eric's post that there's a bit of confusion about the U4D
routines and so on, why are they here etc?
Essentially for Turbo C the compiler helpers are extracted from the c
compiler RTL to be absolutely sure we only link those and nothing else from
that library. These are automatically linked and called "far", which is
correct because init_text and _text are in different segments. This is why
those routines have to have a fixed segment and that's only easily
accomplished in low RAM.
When Tom and I ported the kernel to Watcom we stumbled upon the problem
that U4D was called "near", where it had to be called "far".
Tom even filed an Open Watcom bug for that one, see
http://bugzilla.openwatcom.org/show_bug.cgi?id=193
One way to workaround that was to compile using the medium memory model
and annotate all functions as "near". But that was ugly as hell.
So I decided to implement our own routines, which were easily duplicated
to be both in HMA_TEXT and INIT_TEXT, do a bit of patchobj and as an added
bonus be completely independent of the Watcom RTL.
Now for Watcom HMA_TEXT and INIT_TEXT are in the same segment (group
really) so only one U4D is needed. But that change was *much* later, only
a couple of months ago.
Bart
-------------------------------------------------------
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_id=4721&alloc_id=10040&op=click
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
