Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.os.msdos.programmer Subject: Re: Smaller C compiler Date: Wed, 04 Dec 2013 04:30:27 -0500 Organization: Aioe.org NNTP Server Lines: 106 Message-ID: References: <9e4bfa79-327e-4599-a899-4b9810fa4c65@googlegroups.com> NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.os.msdos.programmer:1105 On Wed, 04 Dec 2013 01:22:21 -0500, Alexei A. Frounze wrote: > On Tuesday, December 3, 2013 9:23:45 AM UTC-8, Rod Pemberton wrote: > At the moment I'm the least concerned about complete implementations of > formatted I/O functions and about the speed of operation. There are some > more pressing areas (cleaning up error checks/messages, implementing > struct and casts). Are you interested in making the program's code ANSI C? > What I'm more concerned about in terms of the standard library is the > common functions operating with long ints, like ftell() and fseek(). > There's no support for 32-bit integers in 16-bit code and yet long ints > can't be shorter than 32 bits and DOS file sizes are 32-bit. I would think TCC and Borland C would be 16-bit too. Except for a few pointer construction macro's and calls to DOS functions, I don't recall much difference between programs compiled by OW as both 16-bit and 32-bit. But, I haven't done much in-depth with OW in a few years. > Looks like as a workaround I'll need to implement _ftell() and _fseek() > taking and returning 32-bit values as pairs of 16-bit ones. :-) There is a reason DJGPP doesn't support 16-bit. There are reasons LCC stopped supporting 16-bit. > Support for longs isn't coming soon. Isn't that the same issue as above? > It'll require reworking of code in a fair number of places (and the most > problematic of them is the code generator) and the code and data size of > the compiler will significantly grow as a result of supporting longs, > likely making it no longer self-compilable in 16-bit. Don't they use different integer sizes in C for different modes on x86? > I might need to start using far pointers to address more than 64K of the > code and then I'd use far pointers for data as well and to support far > pointers, I'll have to support far pointers, meaning even bigger and > complex code generator! :) OK, this isn't the only possible option, but > the long problem needs some research. > IIRC, far and near pointers and some other incompatibilities with the C specifications was why LCC stopped supporting 16-bit. v3.5 and v3.6 supported DOS. v4.1 and v4.2 stopped. I never got around to it, but it looked like the changes were very minor, i.e., like maybe v4.1 or v4.2 had a good chance of being made to support 16-bits. >> However, with some work, you can usually eliminate all >> internal code that uses memory by preferencing file >> I/O functions. So, you can eliminate sprintf(), sscanf(), >> in favor of fprintf(), fscanf(), etc. > > Internally, my *printf()'s share most of the same code. I was looking at your externally declared functions. I thought you were using an available external library for them. >> vsprintf() >> vprintf() >> vfprintf() >> >> I've not use v*printf() functions much. So, it should be >> possible to eliminate these by using other printf functions, >> depending on what you're using them for. If you're using >> them to handle variadic argument lists, then you could use >> a stack. > > Well, the thing is... Take a look at the following declaration > in the compiler: > > void error(char* format, ...); > > How do you think error("Something horrible happened at %d!\n", 404); > gets its arguments out? It uses va_list and vprintf(). Well, you don't have to do it that way. You could use printf() directly. You could use fprintf() directly. You could use sprintf() to a buffer and then a puts(). You could use one printf() for the string and another for the integer, e.g., string looked up in table. You could pass only one string to a custom error function after formatting. > And vprintf() is underneath printf() anyway. In yours? OpenWatcom? DJGPP? ... DJGPP uses a central print routine which is mostly printf(). I'm not sure about OpenWatcom. > I do not feel like disfavoring anything from the used subset > of the standard library functions. It was just suggestions in case you wanted to reduce the quantity to make bootstrapping easier. But, you're bootingstrapping with modern C compilers with complete C libraries, so none of that is probably even needed. Rod Pemberton