Hi!
4-Фев-2004 10:55 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
>> BO> Anyway, -os -s or -oas -s or -oals -s will generally be smaller.
>> Looks like best (default) should be -obhklrs and sometime with
>> -oami[+]-s? Anyway, ATTRIB.OBJ for -obhklrs-oami+-s (almost) identical to
>> result with -oxshki+-s.
BO> hmm, I never got any size improvements for b and r.
With r - most probably. It called "re-order instructions". This is
speed, not size optimization (though, space "safe"). With b - probably,
though, this should be studied (or asked OW team).
BO> Inlining certainly didn't improve.
Of course. :) But sometime (especially for intrinsic functions)
inlining _may_ reduce overall code. Anyway, sometime loss in size is
acceptable. :)
>> BO> perhaps you can replace a few functions by stubs.
>> May you offer some ready stubs?
BO> I had a quick look at attrib. Its biggest user of space is fopen().
BO> fopen() calls fseek() if "append" is set, so you can stub out fseek() as a
BO> no-op.
BO> fopen() also calls open(), and open() is quite a big user too; it
BO> maintains a dynamic array of file handle states (text/binary and so on);
BO> that's where the realloc() comes from.
realloc() for fopen()? Why?
BO> The default array is large enough for attrib
Of course. :)
BO> though so you can stub realloc() too.
BO> Replacements for malloc() and free() will help; don't forget to define
BO> _nmalloc as a malloc caller.
Yes, good point! When I firstly try to reuse my malloc.inc, it gives no
space saving. After defining also _nmalloc() { return malloc(); } and
realloc() { return NULL; } size was decreased to 8160 bytes! This is already
near to BC' 7300 (whereas for BC I redefine setvbuf(), __mkname(),
_setupio() and squezze size of _openfd[] and _streams[])!
BTW, is returning NULL in realloc safe for Watcom's RTL (fopen(), et
el)? When I run new ATTRIB with /@file, it works, but who knows?
Unfortunately, I miss RTL sources to analyze such dependencies myself.
:( Are they big in Watcom? May be, someone resends them for me?
BO> You'll get significant space savings if you replace fopen()/fgetc()/... by
BO> open()/read()/... and even more if you reimplement open() in terms of
BO> _dos_open() (likewise for read) and handle CR/LF yourself.
Good point. I try to export them from SYS.
BO> try to use "wlink .... symtrace realloc_" and so on to see in the mapfile
BO> where it is called from.
Yes, good hint, tlink doesn't allows this. BTW, wlink also shows
module, which contain symbol. Fine.
>> PS: Is there option, which equal to "#pragma on (reuse_duplicate_strings)"?
BO> i don't know. If it exists it would be explained in cguide.ihp
No, I not found there option for this. Moreover, I found this pragma
casually. Studying output of WCC and WPP confirms that they have different
code generators - for example, WPP doesn't merges strings (by default).
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
