Hi!
19-Июл-2004 01:23 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:
>> > Hi, I think it is now clear that Turbo C 2 cannot optimize for 386.
>> > HOWEVER, the NASM parts can still be optimized for 386.
>> ... but then save a few byte by using a different longDIVMODMUL
>> implementation doesn't make much sense.
EA> This was not only about space, it is also about speed. 8086 code is
EA> slow with mul, div, shift of 32 bit numbers, because - at least in
EA> TC - it is implemented in bit-by-bit loops.
This is true only for division, where divisor is more than 2^16-1.
EA> Not sure how often 32 bit
EA> numbers are used in speed-critical way, though.
Not much. I not profile FD kernel, but I doubt that 32-bit division
with big divisors there have noticeable impact (especially on 8086 with
small disks).
EA> We have LDIVMODU and LMULU, and they do:
This is only for Watcom. This is Bart's trying to completely replace
standard Watcom's libraries (and currently no one module from Watcom is
required).
EA> By the way, what is this? -->
>> MATH_EXTRACT=*H_LDIV *H_LLSH *H_LURSH *F_LXMUL
>> MATH_INSERT=+H_LDIV +H_LLSH +H_LURSH +F_LXMUL
EA> ...?
This is instructions for librarian to extract and to add consequent
modules from/to consequent libraries.
EA> It might sound stupid, but I cannot find any place in the sources
EA> where LDIVMODU is actually used?
Calls to __U4M and __U4D generated by compiler itself.
EA> Neither for LMULU... probably it means that our Asm code replaces something
EA> which would be normally present in the compiler as library function?
Yes.
EA> init_LBA_to_CHS ... -> unsigned hsrem = (unsigned)(LBA_address % hs);
EA> So we explicitly disallowed "LBA_address / hs" being > 64k! You could
EA> rewrite
EA> that as:
chs->>Cylinder = (LBA_address>>16 >= hs) ? 0xffffu : (unsigned)(LBA_address/hs);
Nice suggest. :)
unsigned hs = driveparam->chs.Sector * driveparam->chs.Head;
chs->Cylinder = hiword(LBA_address) >= hs ? 0xffffu
: (unsigned)(LBA_address / hs);
hs = (unsigned)(LBA_address % hs);
chs->Head = hs / driveparam->chs.Sector;
chs->Sector = hs % driveparam->chs.Sector + 1;
EA> Similar code exists in LBA_to_CHS - this has different arguments and range
EA> checks, but the core "problem" is the same: An unneeded 32:16=32 division
EA> which can be replaced by a 32:16=16 one
Unortunately, you can't replace "32/16=32" by "32/16=16". :( Because
nature of C/C++ (type promotions), (most) compilers always use generic
32/32=32.
EA> (actually the code even complains
EA> already for results > 1023, one could arguably add support for special
EA> "high cylinder count" extensions like:
EA> - int 13.ee / 13.ef ("add N to cylinder value of next int 13.2/13.3")
Why? Mentioned error message shouldn't happen in real life, because
initdisk.c selects LBA mode for all partitions above 1023 cylinder.
EA> While looking for other 32bit variables, I found a problem in the "dmatch"
EA> structure: dm_dircluster should be of type "CLUSTER", not of type "if FAT32
EA> then ULONG else ...".
You forget about "UWORD reserved", for which #ifdef anyway should be
used. Or union around CLUSTER should be added.
EA> Same for dpb_xrootclst and dpb_xcluster!
Useful, but not neccessary. I, probably, replace ULONG by CLUSTER at
some time, when (and if) will touch consequent headers.
EA> Not sure if you can change this:
>> ULONG l_diroff; /* offset of the dir entry */
EA> ^^^^^ if you use the slot number instead, 16 bit will be enough.
EA> As far as I know, FAT32 directories cannot have > 64k entries each.
ULONG used only in lfnapi.txt. Desynced description. Fixed - see patch
in next letter.
EA> Another dmatch issue: dm_size is LONG but should be ULONG at least for
EA> FAT32. Potential bug cause for processing of files > 2 GB.
Officially, DOS doesn't allows to have files more than 2G. In any case,
dm_size (currently) used only as acceptor for dir_size field, which _is_
unsigned long.
EA> The f_node f_offset is ULONG, too. Nice. Would it be okay to change
EA> f_count from UWORD to UBYTE?
No. This makes misaligned structure, while space savings is low.
EA> time? How about f_mode and f_flags, both 16 bit...?
Hm. Looks like they may be joined (of course, with shifting for f_flags
by two bits higher). But I not yet study the Bart's fnode, so this is
optimization for later.
EA> and both the f_cluster (current) and f_cluster_offset (relative cluster
EA> number within file), both of type CLUSTER.
f_cluster_offset is a _relative cluster number_ in cluster chain
(whereas f_cluster is a _physical number of current cluster_). See
computations at lines 1315-1357 in fatfs.c. Probably, this field may be
removed if fnode structure may be modified.
EA> Finally there is f_offset, which
EA> is ULONG, as told. Note that f_cluster_offset cannot be calculated from
EA> f_cluster - at most you could try to relate it to f_offset, not sure...
It already: see line 1315 in fatfs.c.
EA> The O_OPEN/O_TRUNC/O_CREAT/O_LEGACY bits are all FreeDOS specific!
So what?
EA> The dm_flags structure of dmatch, which seemingly can be used for f_node
As I understand, currently dm_flags field is not used (explicitly) and
used as dummy filer.
EA> Luckily this POTENTIAL bug is triggered nowhere: only the words f_dmod,
EA> F_DMOD, F_DDATE and F_DDIR are used to describe access to dm_flags and
If you see carefully, f_dmod field is used only in lfnapi.c and when
WITHLFNAPI defined (which by default isn't defined). So, this is unnoticed
(by Bart) bug, because Bart in 2033 (or 2034?) removes f_dmod field by
replacing it by F_DMOD mask in f_flags.
EA> f_flags. Conclusion: dm_flags should be defined as a BYTE with the bits
I not (yet) study this question deeply, but looks like you right,
because dmatch structure used as intermediate storage and may be modified
easily. Or, may be better to remove it all and use directory entry contents
directly (in local buffers), without explicit conversion in pop_dmp().
EA> Especially regarding range checks and things, please check RBIL. I think
EA> in non-LARGEFILE mode it was possible to seek to negative offsets for
EA> some purpose.
You may seek in both directions (back and forward) from current
position (SEEK_CUR).
EA> Hm... just noticing that GetBiosKey could HLT to save energy, but
This is only for startup (initial "Press F5 to bypass", selecting boot
source in main.c and config.sys menu). Energy saving here is unimportant.
[...]
Oh, Eric, 500 lines letter, 25k! Too much at my taste. Answers to
second part in next letter.
-------------------------------------------------------
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
