Hi!
3-Фев-2004 09:25 [EMAIL PROTECTED] (Roberto Mariottini)
wrote to <[EMAIL PROTECTED]>:
>> BTW, lguide.ihp says that I may increment stack size by OPTION STACK,
>> but this option affects only .EXE format header. .COM files with and w/o
>> this option are equal. I found in cstart_t.obj mention for __stacksize, but
>> in cstrt086.asm I see that it valid only with "__TINY__", and this variable
>> not explained/mentioned anywhere else (not in *.h nor *.ihp).
RM> TINY is the name of the memory model for COM style executable under DOS.
Yes, I know.
RM> If you pass option /mt (or something like that) to the compiler, it will
RM> automatically define __TINY__ (or some other similar variable).
______________O\_/_________________________________\_/O______________
>wpp @watcom.cfg -mt attrib.c
Error! E068: invalid option
processing command line, switch: -mt
_____________________________________________________________________
O/~\ /~\O
Unlike BCC (which is one WCL+WCC+WPP in one), WCC/WPP doesn't define `tiny'
memory model.
BTW, WCC and WPP are not equal! For example, -ew-oi+ are not supported
by WCC, and it generates worser code!
RM> Note that TINY is essentially SMALL with a different startup code to cope
Of course, I know. But there is two importan differences: (low level)
.COM files set CS to PSP and (high level) in tiny memory model we have less
available memory (because combined code and data segments). Second
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> 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
(for example, execing another executable), whereas with all memory assigned
to program memory handling routines (malloc, free) are simplified.
>> AVB> - BCC generates 9148 bytes of ATTRIB.COM (7306 with
>> ...and 10116 for ATTRIB.COM. Of course - with same object file (in
>> small memory model) difference is only in .EXE header (64 bytes) and in
>> different startup modules (for .COM - cstart_t.obj; for .EXE comes from
>> clibs.lib?).
RM> I don't know watcom, but I think it should use some cstart_*.obj for every
RM> memory model used: t - tiny, s - small, m - medium, c - compact, l - large,
RM> h - huge.
I suggest, all other models include their startups in consequent
library (whereas only tiny model doesn't have its own library).
RM> All the models generate EXE files, but only the tiny model can generate COM
RM> files (or tiny EXE files can be converted to COM files with an utility
RM> called EXE2BIN), in some circumstances (see above).
BC' small model startup uses relocation, so for it EXE-COM conversion
is impossible.
RM> And, yes, the differences between a tiny model EXE and COM is mainly
RM> the EXE header.
Well, TLINK overgenerates header (aligns itr at paragraph boundary,
thus giving extra 480 bytes for executable; for tiny model in .EXE there
also added 256 bytes of code align for IP=100h), and BC' small model startup
is 56 bytes longer. This gives (in compare with tiny.com) +568 for small.exe
and +768 for tiny.exe. This explains why compiling into .COM under BC is
justified. Looks like under Watcom this is less important. :)
BTW, for CuteMouse (which may be loaded by LH into UMB) me needed EXE
header, but, because TLINK generates such big header (512 bytes instead 32)
and because it not allows to make ".COM in .EXE", in CuteMouse I generate
.COM, later converted to .EXE by my COM2EXE utility.
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).
-------------------------------------------------------
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
