Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.msdos.programmer > #1112
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Newsgroups | comp.os.msdos.programmer |
| Subject | Re: Smaller C compiler |
| Date | 2013-12-05 04:23 -0500 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <op.w7l4c1ui5zc71u@localhost> (permalink) |
| References | <be56d70d-0ac7-4d76-a3f9-481808f2899e@googlegroups.com> <op.w7i09vlh5zc71u@localhost> <9e4bfa79-327e-4599-a899-4b9810fa4c65@googlegroups.com> <op.w7j901yn5zc71u@localhost> <0e1f8d5c-505c-490b-a378-cb755658910a@googlegroups.com> |
On Thu, 05 Dec 2013 02:21:15 -0500, Alexei A. Frounze
<alexfrunews@gmail.com> 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
Back to comp.os.msdos.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-01 08:15 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-01 18:42 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-01 19:14 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-02 11:13 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-02 03:21 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-03 06:21 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-02 23:17 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-03 13:31 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 06:05 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-03 10:47 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 21:18 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-03 12:23 -0500
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-03 16:26 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 23:58 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-04 04:31 -0500
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-04 05:01 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-04 02:20 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-05 06:33 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-05 21:37 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-06 12:19 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-06 22:23 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-07 13:48 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-07 16:34 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-08 02:12 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-13 03:32 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-15 04:47 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-15 02:14 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-15 13:21 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-04 23:39 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-05 06:38 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-05 21:40 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-06 04:19 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-06 13:40 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-14 21:07 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 22:22 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-04 04:30 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-04 23:21 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-05 04:23 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-05 21:31 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-10 04:59 +0000
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-10 06:17 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-11 02:36 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-11 13:44 +0000
Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2013-12-10 10:41 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-11 03:06 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-11 10:47 -0500
Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2013-12-11 08:01 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-11 13:40 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-11 22:07 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-25 02:33 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 03:24 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-21 15:55 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-29 17:16 +0000
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-29 21:54 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 19:38 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 19:36 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-30 05:07 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 21:58 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-01-05 19:43 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2014-01-06 15:27 +0000
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-06 19:51 -0500
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2014-01-07 04:27 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-01-06 21:52 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-02-16 22:57 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-02-25 00:17 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-03-01 21:31 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-03-10 01:46 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-04-20 20:19 -0700
Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2014-04-23 11:20 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-04-23 11:41 -0700
Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2014-04-25 06:08 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-09-14 03:06 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-11-09 03:26 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-11-28 04:06 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-12-21 01:56 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-01-10 10:37 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-04-19 23:55 -0700
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2015-04-22 06:13 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-04-22 00:12 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-04-25 21:11 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-05-16 17:49 -0700
Re: Smaller C compiler "Bill Buckels" <bbuckels@mts.net> - 2015-05-19 20:01 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-05-19 18:18 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-08-15 02:13 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-06 15:55 -0700
csiph-web