Hi!
3-Фев-2004 11:16 [EMAIL PROTECTED] (Roberto Mariottini)
wrote to <[EMAIL PROTECTED]>:
>> RM> If you pass option /mt (or something like that) to the compiler, it will
>> RM> automatically define __TINY__ (or some other similar variable).
>> Unlike BCC (which is one WCL+WCC+WPP in one), WCC/WPP doesn't define `tiny'
>> memory model.
RM> I don't understand. You mean:
RM> 1 - Watcom doesn't directly support tiny memory model,
RM> or
RM> 2 - WPP doesn't #define __TINY__ automatically
This is only question of wording, but (2) implies (1). Why you may say
about "direct support for tiny model" if I should define __TINY__ manually
(and __SMALL__ will be defined also)?!
RM> used throughout the whole compilation. The /mt switch can be then passed to
RM> the linker to force an EXE2BIN to the resulting EXE.
/mt option forces adding option "system com" instead "system dos" for
wlink, whereas both `system' are defined in wsystem.lnk. (I suggest, this
should be equal to "/l=com".) wlink doesn't performs separate "exe2bin".
>> difference is worser, but it sometime unimportant, because program may
>> require CS=PSP. So, I think, source should know that it will be compiled
>> into .COM.
RM> Any DOS compiler I know uses small memory model libraries for tiny model.
They _may_ _use small libaries_, but they define __TINY__ _for source_.
At least.
RM> So, I repeat, compiler doesn't distinguish between tiny and small memory
RM> model.
_Internally_ - (usually) yes.
RM> For some low-level related task, the C library sources can have some #ifdef
RM> __TINY__, thoug I've not found one all the times I've looked in the
RM> TC/BC/BC++ C RTL sources.
clib/ctrlbrk.c, clib/harderr.cas, clib/scantod.asm, clib/signal.c,
emu/emurules.asi, emu/fpinit.asm, rtlinc/rules.asi.
>> RM> to link bigger executables) and all free memory allocated to the program by
>> RM> default by
>> RM> the OS (so the startup code should shrink to the maximum needed memory).
>> It shouldn't. This action may/should be performed only when neccessary
RM> Last time I've looked, it did shrink.
Just recheck - you right. :( BC startup frees (to DOS) all memory
beyond stack and RTL controls heap allocation thourgh DOS by _brklvl; there
are no free blocks at heap end. This is unfunny that I don't realize this
earlier, but call to DOS reallocation is hidden very deeply.
>> I suggest, all other models include their startups in consequent
>> library (whereas only tiny model doesn't have its own library).
RM> So you found no cstart_s.obj, cstart_m.obj, cstart_c.obj, cstart_l.obj,
RM> cstart_h.obj in the watcom distribution?
Yes. There are only clib{c,h,l,m,s,ol,om}.lib, emu87.lib, graph.lib,
binmode.obj, commode.obj, cstart_t.obj and dos16m.obj.
RM> Can you explain how the linker can know which is the startup module
RM> (normally the first module on the command line)?
wlsystem.lnk:
______________O\_/_________________________________\_/O______________
system begin dos
libpath %WATCOM%/lib286
libpath %WATCOM%/lib286/dos
format dos ^
end
system begin com
option osname='DOS .COM'
libpath %WATCOM%/lib286
libpath %WATCOM%/lib286/dos
libfile cstart_t.obj
format dos com
end
_____________________________________________________________________
O/~\ /~\O
>> RM> To know where resides the ~1K of difference between BCC
>> RM> executable and WCC executable more info is needed.
>> Probably, this is because more garbage from library is included. At
>> least, generated code for source itself looks good (though, I not measure
>> yet its quality in compare with BCC).
RM> It is possible that OW library is bigger than TC library, but it sounds
RM> strange.
Not neccessary. To make executables smaller, Borland splits its RTL by
many-many-many small files. Even with this there remains extraneous
dependencies, because some function reside in common file (for example,
fseek() and ftell()). I don't know how organized the Watcom RTL sources,
but, probably, there are more common files. In this case, to make
executables smaller, there remains only one way: instead .obj compiler
should generate .lib files, where each function (and common tails) and
each variable placed in its separate library section.
RM> Maybe you can minimize library use?
Check an ATTRIB.C and decise yourself, what from RTL there may be
dropped.
RM> Anyway, the difference is small.
With original compilation (9k/10k) - yes, but for BC I know which (and
how) RTL functions I may replace by my stubs. With this ATTRIB compiled to
7k.
RM> For bigger programs can be beated by better code generation.
-------------------------------------------------------
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
