> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Arkady V.Belousov > Sent: Tuesday, February 03, 2004 10:33 AM > To: [EMAIL PROTECTED] > Subject: RE: [Freedos-devel] Q: watcom > [...] > 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.
I don't understand. You mean: 1 - Watcom doesn't directly support tiny memory model, or 2 - WPP doesn't #define __TINY__ automatically Case 1 is possible, but unlikely. Anyway you can use small model for almost everithing, using the right startup code to "convert" it to a tiny executable, then to a COM file. Case 2 is possible, because WCL can add a -D__TINY__ when calling WPP, and use the small memory model to compile. Another possibility is that __TINY__ is defined only in the startup code compilation, and small memory model is used throughout the whole compilation. The /mt switch can be then passed to the linker to force an EXE2BIN to the resulting EXE. [...] > 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. Any DOS compiler I know uses small memory model libraries for tiny model. BCC links every tiny program with cs.lib, using c0t.obj as startup code instead of c0s.obj. So, I repeat, compiler doesn't distinguish between tiny and small memory model. Only the startup code is different. For some low-level related task, the C library sources can have some #ifdef __TINY__, thoug I've not found one all the times I've looked in the TC/BC/BC++ C RTL sources. > 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. Last time I've looked, it did shrink. The startup code looks for _stacklen and _heaplen, then shink accordingly. Otherwise you coudn't call system() nor exec*() nor spawn*() functions from a tiny model C program. To use more than 64K of total memory in a tiny/small model program, you can use the "far heap": use farmalloc()/farfree() with far pointers. I don't know from which version of TC/BC the far heap is available. > >> 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). So you found no cstart_s.obj, cstart_m.obj, cstart_c.obj, cstart_l.obj, cstart_h.obj in the watcom distribution? Can you explain how the linker can know which is the startup module (normally the first module on the command line)? > 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. The startup module, yes. The library, no. I've said "tiny EXE files can be converted to COM files", not "small EXE ...". [...] > 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). It is possible that OW library is bigger than TC library, but it sounds strange. Maybe you can minimize library use? Anyway, the difference is small. For bigger programs can be beated by better code generation. Ciao ------------------------------------------------------- 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
