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: Thu, 05 Dec 2013 04:23:15 -0500 Organization: Aioe.org NNTP Server Lines: 150 Message-ID: References: <9e4bfa79-327e-4599-a899-4b9810fa4c65@googlegroups.com> <0e1f8d5c-505c-490b-a378-cb755658910a@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:1112 On Thu, 05 Dec 2013 02:21:15 -0500, Alexei A. Frounze wrote: > On Wednesday, December 4, 2013 1:30:27 AM UTC-8, Rod Pemberton wrote: >> On Wed, 04 Dec 2013 01:22:21 -0500, Alexei A. Frounze >> <...@gmail.com> wrote: >> > On Tuesday, December 3, 2013 9:23:45 AM UTC-8, Rod Pemberton wrote: >> > At the moment I'm the least concerned about [...] >> >> Are you interested in making the program's code ANSI C? > > Which program's, how and why? > Smaller C's source files. Do you have any plans to make them be ANSI or comply with GCC's '-ansi' flag? (No.) I think you stated in one of the other posts that the code is C89 exempt C++ style comments. I thought I saw many more errors and warnings with '-ansi' than that would or should produce, but I'll double check. DJGPP v2.03 uses an old version of GCC. v2.04 has problems on real-mode DOS, but is fine in dos console windows. DJGPP project is updating GCC for v2.04, but not v2.03, AFAIK. >> > 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. > > And? You could check to see if TCC and Borland C use long ints for ftell() and fseek() too, or if they use some other solution, e.g., perhaps they use near pointers, if you don't already know what they do. I think (don't quote me) OpenWatcom, at least v1.3, used a few non-standard returns. >> > Support for longs isn't coming soon. >> >> Isn't that the same issue as above? > > What do you mean by that? Isn't implementing longs on 16-bit the same issue as needing to implement "32-bit values as pairs of 16-bit ones"? Or, was that longs for 32-bit instead? >> Don't they use different integer sizes in C for different modes on x86? > > Obviously, some do. Not sure if you had any specific *they* in mind. :) No, just thinking that common sizes for 16-bit might fit better with native 16-bit x86 assembly assembly size, than using 32-bit sizes. >> > 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. > > What happened? Uh, I don't recall now... See "4.html" for LCC v4.1's changes from v3.x: http://zeq2.com/SVN/Source/Engine/tools/lcc/doc/4.html I vaguely recall reading that there was a problem with pointer compliance for C89 with DOS versions, so they dropped DOS support. I also vaguely recall that there were differences in integers. But, I'm not able to confirm either, at the moment. I did have a file with a few notes I made: lcc42 -no DOS support - incompatible w/3.x versions lcc41 -lists changes from 3.x versions lcc36 -last DOS version lcc35 -last DOS version with included binaries NASM 0.98.39 has support files for LCC for Linux in src/lcc NASM 0.99.00 has support files for LCC v3.6 LCC 3.6 has x86-dos reference in bind.c LCC 3.6 has two "dos" dir's in include\x86 and x86 LCC 4.1 and 4.2 don't x86nasmw.md - NASM machine description for LCC 4.1 on Windows ns32k093.zip - DJGPP changes for LCC v3.2 Quake3 Virtual Machine specification - modified LCC used for Q3VM > Did they not agree on whether the keyword far applies to > (associates with) the pointer or to(with) the object/function > pointed to? ???? Was that MASM vs. NASM humor? E.g., MASM dword/tword/qword/fword etc. vs. NASM brackets. Or, was that C indirection or dereference humor? >> >> 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. > > Don't forget that error() != printf(), error() does more than a mere > printf(). If I replace all calls to error() with 2 calls, first, to > printf(), second, to something else, error2() or exit2(), then I lose > memory on all those additional instructions doing additional calls. It won't matter for exit(). If error() calls exit(), it won't matter then either. Application terminated. OS recovers memory. Yes? ... Rod Pemberton