Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
alexfru

USA,
03.01.2014, 06:46
 

Smaller C compiler (Announce)

Post reply

Hello fellow DOS lovers!

I'm not sure whether this fits best the Announce category or the Misc one, (moderator(s), feel free to correct).

I've come across this thread, Old 8086 version of pcc spotted (cross-compiles to DOS), and I'd like to share with you my recent work in the field.

For the past year I've been working in my spare time on a C compiler that could potentially target DOS. And, in fact, it already can. :)

Meet Smaller C!

Smaller C in not too many words (more on github):

- is much like the original Small C by Cain/Hendrix/etc and Micro-C by Dunfield, but with normal ANSI/C89 syntax and behavior (=no foul play in expressions as in Micro-C), work is underway to support more of C89

- generates NASM-agreeable 16- or 32-bit i80386 assembly code, and should be fairly easily adaptable to other assemblers if needed (I've been told, it takes an hour to adapt it to NBASM)

- -seg16t,-seg16,-flat16 options are for the 16-bit tiny/small memory models (ints and pointers are 16-bit, pointers are near)

- -seg32,-flat32 options are for 32-bit code (ints and pointers are 32-bit, pointers are near)

- -huge option is for a memory model similar to the huge memory model found in Borland/Turbo C/C++ compilers (ints and pointers are 32-bit, pointers are physical addresses, transparently converted into segments and offsets, no need to mess with far, MK_FP(), FP_SEG(), FP_OFF() and the like, you can pretend you're in 32-bit mode!; this should help with porting code to DOS or even writing new code for DOS)

- is trivially compilable with any C89+ compiler (Turbo/Borland C/C++, Open Watcom C/C++, djgpp, gcc, you name it) and can run in DOS

- (re)compiles itself (you can already make a DOS .EXE of Smaller C using only Smaller C (compiled with another compiler or itself) and NASM (2.03 or better), no linker needed)

- doesn't yet provide libc, though it should be easy to implement a basic library for DOS (the compiler itself needs only a handful of ctype/string/stdlib/stdio functions to operate and those are already available for bootstrapping for DOS)

- BSD licensed


More details (live document) can be found here, in the Wiki.

In the near future I'm going to add support for struct, short and long.

You're most welcome to play with Smaller C, report bugs and discuss it (and contribute:).

Alex
P.S. Robert, indeed, I'm the author of the Frounze Commander. :) Thanks for my new account on the forum!
alexfru

USA,
17.02.2014, 07:59

@ alexfru
 

Smaller C compiler

Post reply

Basic support for struct/union has just been submitted.

You can do everything with struct and union, except:
- bit-fields, flexible array members
- tight packing (members are naturally aligned)
- passing/returning to/from functions by value; pass/return by reference instead
- initializing at definition time via = { initializer(s) }

Assignment, ?:, ->, ., (unsigned)&((struct someTag*)0)->someMember are OK.

Enjoy. Please report bugs.
Oso2k

19.02.2014, 18:46

@ alexfru
 

Smaller C compiler

Post reply

> Basic support for struct/union has just been submitted.
>
> You can do everything with struct and union, except:
> - bit-fields, flexible array members
Does this mean you allow this funky bit of C structs?

struct Parent
{
char* str;
}

struct Child
{
struct Parent;
int length;
}

struct Child c;
c.str = "Hello World!";
c.length = strlen( c.str );
alexfru

USA,
19.02.2014, 21:04

@ Oso2k
 

Smaller C compiler

Post reply

> Does this mean you allow this funky bit of C structs?
> ...
You could try, right? :)

This does compile:


int main(void)
{
  struct Parent
  {
    char* str;
  }; // note the semicolon

  struct Child
  {
    struct Parent p; // note the member name p
    int length;
  }; // note the semicolon

  struct Child c;
  c.p.str = "Hello World!"; // note the p
  c.length = strlen( c.p.str ); // note the p

  return 0;
}
alexfru

USA,
25.02.2014, 09:19

@ alexfru
 

Smaller C compiler

Post reply

New things:
- short
- long (32-bit and huge mode(l)s only)
- improved extern (now extern directives are generated for NASM automatically as needed, not based on whether or not you use extern in C)
- one bug fixed
alexfru

USA,
02.03.2014, 06:29

@ alexfru
 

Smaller C compiler

Post reply

New things:
- typedef
- __func__
- bugfixes
alexfru

USA,
10.03.2014, 09:45

@ alexfru
 

Smaller C compiler

Post reply

New things:
- enum
- #pragma pack()
- bugfix
alexfru

USA,
21.04.2014, 05:04

@ alexfru
 

Smaller C compiler

Post reply

Improvements/New things:
- bugfixes
- support initialization of multidimensional arrays
- support initialization of structures
- support initialization of structures and arrays inside functions
- support static inside functions

The compiler should now be much more usable.
alexfru

USA,
14.09.2014, 12:03

@ alexfru
 

Smaller C compiler

Post reply

I've uploaded binaries for DOS and most of the standard library.

Note: a few things are still missing from the library, most notably: <time.h> functionality, *scanf() functions.

Everyone's welcome to play with the compiler and report bugs.

How to install the .zip file downloaded from GitHub:

1. Create C:\SMLRC (any hard disk or name will do, but make the full path as short as possible) and copy into it the following subdirectories of the .zip file:
BIND
INCLUDE
LIB
TESTS

2. Include C:\SMLRC\BIND in the environment variable PATH

3. Don't forget to have NASM (2.10 is good) installed and also available via PATH

You should now be able to compile the following example from TESTS\hw.c:

/*
How to compile for DOS (all mode(l)s: tiny/.COM, small/.EXE, huge/.EXE):
smlrcc -dost hw.c -o hwdt.com
smlrcc -doss hw.c -o hwds.exe
smlrcc -dosh hw.c -o hwdh.exe
*/
#include <stdio.h>

int main(void)
{
puts("Hello, World!");
return 0;
}

I suggest to stick to the huge memory mode(l) as it supports 32-bit types such as long the functions that consume or return these types. In this mode(l) you can allocate all the available conventional memory via malloc() and you're not limited to objects smaller than 64KB.

The huge memory mode(l) is selected with the "-dosh" option, but you don't need to specify it explicitly when using a DOS version of smlrcc.

What else to know?

smlrcc can consume one or more of .c, .asm, .o or .a files and make an executable out of them.

If the command line is too long (over some 120 characters), you can put it into a file, say, mycmd.txt, and invoke smlrcc with @mycmd.txt (note the @ prefix) and it will extract the command line parameters from the file mycmd.txt. The linker (smlrl) supports this as well.

smlrcc supports the following useful options:
-c (compile only, don't link)
-S (compile to assembly only)
-v (verbose; show executed commands)
-map <mapfile> (produce the map file together with the binary)

You can compile your .c/.asm/.o files directly to a .a library file if you invoke smlrcc like so:
smlrcc [options] <file(s)> -c -o mylib.a

There's more but the documentation hasn't been updated for a while and so here I'm giving the most basic info only.

Enjoy.
alexfru

USA,
09.11.2014, 12:18

@ alexfru
 

Smaller C compiler

Post reply

I've just added support for Windows as both a host and a target platform.

This means that there are now executables and libraries for both DOS and Windows and you can develop on either platform for either platform.

The standard C library is practically complete (up to what the compiler supports in terms of the C language) and should be usable.

There have been some other changes and improvements in the meantime.
alexfru

USA,
28.11.2014, 13:13

@ alexfru
 

Smaller C compiler

Post reply

I've updated the documentation (smlrcc.exe, smlrl.exe, standard library):
https://github.com/alexfru/SmallerC/wiki
alexfru

USA,
21.12.2014, 11:28

@ alexfru
 

Smaller C compiler

Post reply

I've added Linux support (library and binaries).

So, finally, all 3 platforms (DOS, Windows and Linux) are the host and the target platforms.
alexfru

USA,
10.01.2015, 19:39

@ alexfru
 

Smaller C compiler

Post reply

I've added an option (-ppg) to smlrcc to invoke gcc as a preprocessor and included the va_* macros in stdarg.h.
This should help until there's a decent preprocessor in Smaller C.

It looks like DJGPP's gcc.exe works as well.

Alex
alexfru

USA,
20.04.2015, 08:52

@ alexfru
 

Smaller C compiler

Post reply

For those interested, it's now possible to pass and return structures by value.
alexfru

USA,
26.04.2015, 06:12

@ alexfru
 

Smaller C compiler

Post reply

A few important bugfixes are uploaded.
Rugxulo

Homepage

Usono,
07.05.2015, 10:33

@ alexfru
 

Smaller C compiler (tests under emulation)

Post reply

I never read nor frequented news://alt.os.development before,
but I somehow stumbled upon an old post from last October:

> Another thing that could help with testing under DOS is some
> simple tooling and scripting to build the compiler, write it
> and a bunch of tests and batch files to a floppy image, run
> stuff from it in a VM, then get back the log from the floppy
> image. I haven't researched automation with DOSBox, VirtualBox
> and the like. I imagine, not everyone of them provides
> programmatic interface to create/update/start/stop a VM.
I'm far from an expert. Plus most people indeed don't have
the interest to attempt things like this (at least not for DOS).

BTW, in an effort to be brief, I'll just post a few relevant
links here:

1). http://en.wikipedia.org/wiki/Mtools (also, 7-Zip 7z can extract)
2). ftp://ftp.winimage.com/extrac21.zip
3). http://www.freedos.org/software/?prog=vmsmount
4). http://www.freedos.org/wiki/index.php/VirtualBox_-_Chapter_6
5). http://en.wikibooks.org/wiki/QEMU/Devices/Storage
6). http://www.dosemu.org/docs/README/1.4/x724.html
7). http://rufus.akeo.ie/
8). http://qemu.weilnetz.de/

I've still been working on my single-floppy .img (FreeDOS) MetaDOS
distribution (0.2, still unreleased). The original version was
ultra minimal and somewhat useless (and broken). This one, while
still somewhat weak, is heavily improved. It uses packet drivers
to enable networking (mTCP's FTP, Watt-32 built Wget or Links2),
at least under VBox or QEMU.

My point is that I (privately, manually) run naive tests occasionally
just to make sure some things (still) work, e.g. rebuilding old NASM,
rebuilding the kernel, some random other silly things. E.g. my TP-ish
Befunge-93 interpreter, which I sometimes use (snapshot from FTP)
FreePascal's ppcross8086 (Win32-hosted cross-compiler) under HX (since
there still isn't a self-hosted DOS version!). BTW, they don't even
use NASM (nor WLIB) by default anymore, only internal bin writer.

I did see that you said you'd filed bugs against OpenWatcom. I still
haven't tried the 2.0-pre releases, although Jiri did update his
unofficial snapshot last month. I keep meaning to try to rebuild
NASM with it (which is, AFAIK, totally broken and unsupported
for that compiler due to bugs), but it's not important enough.
I don't even remember when it last built correctly (with OW),
probably 2.09-ish. Not sure about DJGPP, haven't tried natively.
I think they only cross-compile (for DOS via DJGPP) from Linux
, which might make things harder (./configure never works well
anywhere else).

http://sourceforge.net/projects/openwatcom/files/current-build/

Did I mention that I'm using a RAM driver (now unmaintained) by
Jason Hood that won't assemble in newer NASMs (due to his very
weird nasm.mac macros)? Yeah, fun fun fun. Oh, and the FreeDOS
kernel also requires NASM to rebuild.

Did any of this help? I feel like I just mostly rambled (again, sigh).
alexfru

USA,
08.05.2015, 09:32

@ Rugxulo
 

Smaller C compiler (tests under emulation)

Post reply

> I never read nor frequented news://alt.os.development before,
> but I somehow stumbled upon an old post from last October:
>
> > Another thing that could help with testing under DOS is some
> > simple tooling and scripting to build the compiler, write it
> > and a bunch of tests and batch files to a floppy image, run
> > stuff from it in a VM, then get back the log from the floppy
> > image. I haven't researched automation with DOSBox, VirtualBox
> > and the like. I imagine, not everyone of them provides
> > programmatic interface to create/update/start/stop a VM.
>
> I'm far from an expert. Plus most people indeed don't have
> the interest to attempt things like this (at least not for DOS).
>
> BTW, in an effort to be brief, I'll just post a few relevant
> links here:
>
> 1). http://en.wikipedia.org/wiki/Mtools (also, 7-Zip 7z can extract)
> 2). ftp://ftp.winimage.com/extrac21.zip
> 3). http://www.freedos.org/software/?prog=vmsmount
> 4). http://www.freedos.org/wiki/index.php/VirtualBox_-_Chapter_6
> 5). http://en.wikibooks.org/wiki/QEMU/Devices/Storage
> 6). http://www.dosemu.org/docs/README/1.4/x724.html
> 7). http://rufus.akeo.ie/
> 8). http://qemu.weilnetz.de/
I do have my own tools to create a FAT12-formatted floppy and populate
it with files. But the idea of writing DOS batch files for this is
putting me off. :)

> I've still been working on my single-floppy .img (FreeDOS) MetaDOS
> distribution (0.2, still unreleased). The original version was
> ultra minimal and somewhat useless (and broken). This one, while
> still somewhat weak, is heavily improved. It uses packet drivers
> to enable networking (mTCP's FTP, Watt-32 built Wget or Links2),
> at least under VBox or QEMU.
Is it just FreeDOS kernel w/ network support?

> My point is that I (privately, manually) run naive tests occasionally
> just to make sure some things (still) work, e.g. rebuilding old NASM,
> rebuilding the kernel, some random other silly things. E.g. my TP-ish
> Befunge-93 interpreter, which I sometimes use (snapshot from FTP)
> FreePascal's ppcross8086 (Win32-hosted cross-compiler) under HX (since
> there still isn't a self-hosted DOS version!). BTW, they don't even
> use NASM (nor WLIB) by default anymore, only internal bin writer.
>
> I did see that you said you'd filed bugs against OpenWatcom. I still
> haven't tried the 2.0-pre releases, although Jiri did update his
> unofficial snapshot last month. I keep meaning to try to rebuild
> NASM with it (which is, AFAIK, totally broken and unsupported
> for that compiler due to bugs), but it's not important enough.
Is the last commercial version of Watcom (10.x/11.x?) less buggy,
do you know? After all, it was Watcom with which a bunch of popular
games for DOS (e.g. Doom, Descent, etc) were compiled.

> I don't even remember when it last built correctly (with OW),
> probably 2.09-ish. Not sure about DJGPP, haven't tried natively.
> I think they only cross-compile (for DOS via DJGPP) from Linux
> , which might make things harder (./configure never works well
> anywhere else).
>
> http://sourceforge.net/projects/openwatcom/files/current-build/
>
> Did I mention that I'm using a RAM driver (now unmaintained) by
> Jason Hood that won't assemble in newer NASMs (due to his very
> weird nasm.mac macros)? Yeah, fun fun fun. Oh, and the FreeDOS
> kernel also requires NASM to rebuild.
>
> Did any of this help? I feel like I just mostly rambled (again, sigh).
Not really/not yet. :)

Btw, I'm working on implementing BSS section support in Smaller C,
so the binaries are going to shrink somewhat (~40KB for a set of
smlrc.exe, smlrl.exe, smlrcc.exe). Of course, something like
PKLITE could be used to make them even smaller and the library
files can have their local symbols stripped off, but even now
my compiler fits onto a 1.44MB floppy together with NASM without
using compression. :)

One day I was pondering the idea of making a tiny DOS that would
only support the functions used by the compiler. :) The problem
is NASM, which uses lots of DOS functions. OTOH, there's FASM,
but it isn't compatible enough with NASM/Smaller C. A development
system on a floppy is kinda cool. :)
Rugxulo

Homepage

Usono,
08.05.2015, 17:10

@ alexfru
 

Smaller C compiler (tests under emulation)

Post reply

> I do have my own tools to create a FAT12-formatted floppy and populate
> it with files. But the idea of writing DOS batch files for this is
> putting me off. :)
What's the problem with .BATs? Too tedious? Anyways, I'm starting to wonder if makefiles (e.g. 16-bit port of Dmake) would be better (for testing).

> > I've still been working on my single-floppy .img (FreeDOS) MetaDOS
> > distribution (0.2, still unreleased).
>
> Is it just FreeDOS kernel w/ network support?
Yes, of course. I didn't write any major code, just simplified things and made it easier (at least for me). Unfortunately, some things still trip me up (e.g. different QEMU versions or iBiblio quirks), but it mostly works well.

> Is the last commercial version of Watcom (10.x/11.x?) less buggy,
> do you know? After all, it was Watcom with which a bunch of popular
> games for DOS (e.g. Doom, Descent, etc) were compiled.
I'm no expert, but I think those ancient versions are even worse. Even OW 1.4 (or 1.8) added and fixed lots of stuff. If anything, newer versions are probably regression-tested better than ever.

I haven't followed them closely in recent years. Not sure why they are so slow to have a newer release. Probably too ambitious (adding AMD64, among other things). Probably should've just done a bugfix-only release or two. Also the buyout of Sybase by SAP probably didn't help.

> > Did any of this help? I feel like I just mostly rambled (again, sigh).
>
> Not really/not yet. :)
I honestly don't know what you're trying to do here.

> Btw, I'm working on implementing BSS section support in Smaller C,
> so the binaries are going to shrink somewhat (~40KB for a set of
> smlrc.exe, smlrl.exe, smlrcc.exe). Of course, something like
> PKLITE could be used to make them even smaller and the library
> files can have their local symbols stripped off, but even now
> my compiler fits onto a 1.44MB floppy together with NASM without
> using compression. :)
Sounds good. Though I'm not sure what advantages PKLITE has over UPX.

> One day I was pondering the idea of making a tiny DOS that would
> only support the functions used by the compiler. :) The problem
> is NASM, which uses lots of DOS functions. OTOH, there's FASM,
> but it isn't compatible enough with NASM/Smaller C. A development
> system on a floppy is kinda cool. :)
RxDOS was GPL, written in assembly, but quite buggy. Not sure if that would help you here. IIRC, originally MASM, but there was also an A86 port. Not sure if that one guy ever finished his conversion to NASM.

The problem with FASM (for 16-bit DOS target) is lack of OMF/OBJ support. And the problem with FreeDOS' kernel is reliance on quasi-standard 16-bit DOS-isms and (now) compact model.
tom

Homepage

Germany (West),
08.05.2015, 20:31

@ Rugxulo
 

Smaller C compiler (tests under emulation)

Post reply

> And the problem with FreeDOS' kernel is reliance on quasi-standard 16-bit
> DOS-isms and (now) compact model.
Please explain what kind of problems this is causing
Rugxulo

Homepage

Usono,
09.05.2015, 02:57

@ tom
 

Smaller C compiler (tests under emulation)

Post reply

> > And the problem with FreeDOS' kernel is reliance on quasi-standard
> > 16-bit DOS-isms and (now) compact model.
>
> Please explain what kind of problems this is causing
Tom, I wasn't trying to yet again whine about ye olde OpenWatcom license wars. I was actually referring to his idea of "making a tiny DOS that would only support the functions used by the compiler". So unless Smaller C eventually implements those 16-bit DOS extensions and compact model, it's probably not (easily) going to support rebuilding the FreeDOS kernel. Didn't DOS-C formerly use small model?
alexfru

USA,
10.05.2015, 00:25

@ Rugxulo
 

Smaller C compiler (tests under emulation)

Post reply

> > I do have my own tools to create a FAT12-formatted floppy and populate
> > it with files. But the idea of writing DOS batch files for this is
> > putting me off. :)
>
> What's the problem with .BATs? Too tedious? Anyways, I'm starting to wonder
> if makefiles (e.g. 16-bit port of Dmake) would be better (for testing).
.BATs are a bit too primitive to my taste and insufficiently standardized/
widespread. I wouldn't be able to use them under Linux, for example.
They'd have to be confined to DOS/Windows environment. Makefiles aren't
the best either. There are different makes and Windows doesn't provide
make out of the box.

> > Is the last commercial version of Watcom (10.x/11.x?) less buggy,
> > do you know? After all, it was Watcom with which a bunch of popular
> > games for DOS (e.g. Doom, Descent, etc) were compiled.
>
> I'm no expert, but I think those ancient versions are even worse. Even OW
> 1.4 (or 1.8) added and fixed lots of stuff. If anything, newer versions are
> probably regression-tested better than ever.
The kinds of bugs I've found in OW (and heard others stumble upon)
suggest that testing in OW is rather poor if existent at all. The OW's
very own website says that 3rd party commercial tests were lost in
transition of the project to open source. They couldn't be open sourced.

> > > Did any of this help? I feel like I just mostly rambled (again, sigh).
> >
> > Not really/not yet. :)
>
> I honestly don't know what you're trying to do here.
What do you mean by that?

> Sounds good. Though I'm not sure what advantages PKLITE has over UPX.
Probably none. Think of it as a recognizable brand name rather than
a specific .exe compressor.

> The problem with FASM (for 16-bit DOS target) is lack of OMF/OBJ support.
It is a problem to a degree. OMF/OBJ itself is a huge problem. It's an
overly complicated format that pretty much nobody implemented properly.
We may talk about conspiracy theories behind different OMF/OBJ tools
being incompatible with one another, but it's a too big and too quirky
thing to deal with.

My compiler's linker consumes ELF32 object files, no matter if it's 32-bit
code for Linux or for Windows or 16-bit code for DOS. NASM supports
16-bit relocations in ELF32 and that's all that's really needed.
Segments can be organized around that, if needed.

> And the problem with FreeDOS' kernel is reliance on quasi-standard 16-bit
> DOS-isms and (now) compact model.
Yeah, far pointers and such peering out of every corner. :)
Rugxulo

Homepage

Usono,
10.05.2015, 04:46

@ alexfru
 

Smaller C compiler (tests under emulation)

Post reply

> > What's the problem with .BATs? Too tedious? Anyways, I'm starting
> > to wonder if makefiles (e.g. 16-bit port of Dmake) would be better
> > (for testing).
>
> .BATs are a bit too primitive to my taste and insufficiently standardized/
> widespread. I wouldn't be able to use them under Linux, for example.
> They'd have to be confined to DOS/Windows environment. Makefiles aren't
> the best either. There are different makes and Windows doesn't provide
> make out of the box.
Then use pre-existing portable tools like GNU Make or OpenWatcom Wmake(r) or Dmake.

> The kinds of bugs I've found in OW (and heard others stumble upon)
> suggest that testing in OW is rather poor if existent at all. The OW's
> very own website says that 3rd party commercial tests were lost in
> transition of the project to open source. They couldn't be open sourced.
Maybe so, I don't know. I'd be surprised if they didn't glean a lot from other sources, esp. GCC. Dunno what tests they use currently. But be sure to try again with the latest unofficial build from a month ago.

> > > > Did any of this help? I feel like I just mostly rambled (again,
> sigh).
> > >
> > > Not really/not yet. :)
> >
> > I honestly don't know what you're trying to do here.
>
> What do you mean by that?
I thought you wanted help with running tests under emulators and extracting files from images. I don't know what else would apply here.

> > The problem with FASM (for 16-bit DOS target) is lack of OMF/OBJ
> support.
>
> It is a problem to a degree. OMF/OBJ itself is a huge problem. It's an
> overly complicated format that pretty much nobody implemented properly.
> We may talk about conspiracy theories behind different OMF/OBJ tools
> being incompatible with one another, but it's a too big and too quirky
> thing to deal with.
A few years ago, I already experienced a lot of that trying to use ancient Oberon-M 1.2 for DOS. We had a long thread about it here. That (freeware) compiler is very old (1991), back when DOS still came with LINK. Obviously various vendor extensions and adding 32-bit support threw a lot of wrenches into everything. I had to do a tiny hack myself to the resulting (main) .OBJ just to get it to work. Japheth did kindly patch JWlink for me. I tested a bunch of linkers: some worked, some didn't. It's definitely complicated. So I don't really blame you for using something else entirely.
Rugxulo

Homepage

Usono,
21.05.2015, 03:26
(edited by Rugxulo, 21.05.2015, 03:40)

@ Rugxulo
 

Smaller C compiler (tests under emulation)

Post reply

> > .BATs are a bit too primitive to my taste and insufficiently
> standardized/
> > widespread. I wouldn't be able to use them under Linux, for example.
> > They'd have to be confined to DOS/Windows environment. Makefiles aren't
> > the best either. There are different makes and Windows doesn't provide
> > make out of the box.
>
> Then use pre-existing portable tools like GNU Make or OpenWatcom Wmake(r)
> or Dmake.
Well, I don't mean makefiles are perfect. Admittedly, I've only done semi-trivial ones, and the host OS shell is the main problem. Some makefiles rely way too heavily on host features, and it's admittedly not easy to avoid that.

Just for example, P5 Pascal 1.1 (bytecode compiler): he used many (DOS-unfriendly) .BAT and .SH files separately for his compilation and tests. Presumably that's the kind of duplication of effort which you're trying to avoid. I did myself write a simple GNUmakefile (only to use GPC, not IP) that did a subset of that. Hence I was able to build and test on DOS, Linux, and Windows (with a few macro substitutions). IIRC, I used DJGPP GNU Make 3.79.1, Lucid Puppy Linux's GNU Make 3.81, and FreePascal's GNU Make 3.80. (Yes, even FPC relies on makefiles sometimes.) EDIT: DJGPP /beta/v2gnu/ has mak40b.zip and mak41b.zip nowadays.

OpenWatcom's Wmake is also portable, and Wmaker (real mode) should work anywhere with any extender (in theory). Same with old 16-bit DOS build of Dmake. I've not really tested Dmake on Windows or Linux, but a quick search the other day did show that prebuilt binaries exist, at least for Windows, e.g. some old Perl version, even Apache OpenOffice (though I have no idea if they still actively use or maintain such build scripts).

A lot of people these days (besides ignoring DOS entirely) prefer more robust tools, almost scripting languages, like Cmake or Scons. Obviously GNU relies (too) heavily on Bash + POSIX utilities + AutoTools + GNU Make.

http://www.gnu.org/prep/standards/standards.html#Utilities-in-Makefiles

I guess there's not much else to say. You probably knew most of this. I just don't know what else to tell you. Nothing's perfect.

P.S. I was also (barely) going to suggest you look at Louis Santillan's picotap, but apparently he removed DOS support ("May revisit that later")! Dunno why. Maybe it was too kludgy. You'd have to email him. I still have his old .ZIP but never really used it. https://github.com/lpsantil/picotap
alexfru

USA,
17.05.2015, 02:51

@ alexfru
 

Smaller C compiler

Post reply

Improvements:
- .bss section (smaller binaries)
- lifted limitations on string literal length (hooray!)
- better concatenation of adjacent string literals
(even across preprocessor directives)
- type specifiers may occur in any order
(e.g. "unsigned short int" and "int short unsigned")
alexfru

USA,
15.08.2015, 11:20

@ alexfru
 

Smaller C compiler

Post reply

What's new in the compiler?
- DPMI support and DPMI binaries of the compiler itself
- linker bugfixes
- support for a.out (OMAGIC) executable format with relocation records
https://github.com/alexfru/SmallerC

Btw, if you're using NASM with Smaller C or alone, you may want to check out YASM. It's noticeably faster on large files than NASM (and you can just rename it to nasm.exe in order to use with Smaller C).

Alex
alexfru

USA,
07.09.2015, 00:57

@ alexfru
 

Smaller C compiler

Post reply

What's new in the compiler?
- it can use FASM instead of NASM when compiling 32-bit protected
mode code (DOS/DPMI32, Windows, Linux)

There's now a wrapper around FASM, n2f.c, which if compiled into
nasm[.exe] will transparently convert the assembly code generated
by smlrc to the syntax and layout that FASM understands and invoke
FASM on it. A kind of NASM replacement/substitution. This tool
isn't general purpose, it converts only a very restricted subset of
assembly code from NASM syntax to FASM syntax and layout.

What does this mean? Well, for one thing, FASM is faster and
smaller than NASM, so you can make a floppy with the compiler
and the assembler and, say, DOS/DPMI32 library and you'll still
have about a half of the space free on the floppy. And you can
run this even in DOSBox without fearing that NASM would take
forever to assemble code with many jump instructions and without
having to give many many more CPU cycles to DOSBox.

Another thing is that this makes Smaller C fully and easily
portable to any x86 OS running apps in 32-bit protected mode.
Smaller C can fully recompile its libraries and itself if
there's NASM or YASM in your system. If porting NASM or YASM
is somehow problematic or undesirable, there's now another
option, FASM. FASM is written in 80386 assembly and can
recompile itself without needing any other tools. So, you
only need to teach FASM to use your OS syscalls and do the
same with the Smaller C library.

Alex
alexfru

USA,
14.06.2016, 11:24

@ alexfru
 

Smaller C compiler

Post reply

Btw, did I tell you that Smaller C has basic floating point support now?
In short:
- float and double are both 32-bit single precision
- ++, --, +=, -=, *=, /= aren't yet supported with floats
- floats not supported in *scanf() and there's no strtod(), atof() (but *printf() should just work with floats)
- most of ANSI C's <math.h> is in with some extras from C99

(I shouldn't probably mention on this forum that it can also make Windows GUI apps (there's a small clock demo for SDL2.dll))

Alex
Rugxulo

Homepage

Usono,
19.06.2016, 02:22

@ alexfru
 

Smaller C compiler

Post reply

> Btw, did I tell you that Smaller C has basic floating point support now?
I did notice already on Github, but none of my wimpy code needs it.

> (I shouldn't probably mention on this forum that it can also make Windows
> GUI apps (there's a small clock demo for SDL2.dll))
I saw that too but never tried it. However, since you mentioned it, just FYI ....

At one time the remake of Atomiks (by Mateusz Viste), at least the Win32 .EXE using SDL 1.2, ran under HX/DOS. So ....
Rugxulo

Homepage

Usono,
04.09.2015, 03:19

@ alexfru
 

Smaller C compiler

Post reply

(BTW, sorry for procrastinating and not testing this sooner. You've done very good work!)

> I've added an option (-ppg) to smlrcc to invoke gcc as a preprocessor and
> included the va_* macros in stdarg.h.
> This should help until there's a decent preprocessor in Smaller C.
>
> It looks like DJGPP's gcc.exe works as well.
It looks like you're using "-nostdinc -isystem". Why not just use "-I" instead since it prepends your dir before searching the other typical standard system header places. (GCC online manuals): -I, -isystem

Also, you should probably also use "-U__GNUC__" since some macros may depend on it. (For instance, I was optionally using case ranges #if defined _GNUC__ || defined __TINYC__ , e.g. "case 'a' ... case 'z':".) In other words, if you don't do this and use GCC as preprocessor, SmallerC will choke on faulty code.
alexfru

USA,
04.09.2015, 07:22

@ Rugxulo
 

Smaller C compiler

Post reply

> (BTW, sorry for procrastinating and not testing this sooner. You've done
> very good work!)
Thanks! Nice to hear someone's at least trying it out. :)

> > I've added an option (-ppg) to smlrcc to invoke gcc as a preprocessor
> and
> > included the va_* macros in stdarg.h.
> > This should help until there's a decent preprocessor in Smaller C.
> >
> > It looks like DJGPP's gcc.exe works as well.
>
> It looks like you're using "-nostdinc -isystem". Why not just use "-I"
> instead since it prepends your dir before searching the other typical
> standard system header places. (GCC online manuals):
> -I,
> -isystem
Smaller C does not support all of the C language (that applies to the library as well) and the compiler proper uses a fixed amount of memory to keep track of declarations and symbols. It is unlikely that some random stuff pulled in from, say, DJGPP include directories (by mistake or intentionally) will do much good. So, the location of system headers is overridden to prevent mixing and matching system headers, especially while having these limitations.

> Also, you should probably also use "-U__GNUC__" since some macros may
> depend on it. (For instance, I was optionally using case ranges #if defined
> _GNUC__ || defined __TINYC__ , e.g. "case 'a' ... case 'z':".) In other
> words, if you don't do this and use GCC as preprocessor, SmallerC will
> choke on faulty code.
Maybe. Right now you can depend on __SMALLER_C__ for stuff that's intended for Smaller C and when it's not defined do something else for gcc or another compiler. Given the above limitations, you still pretty much have to write specialized code for Smaller C, in which case checking first for __SMALLER_C__ isn't that much different from checking for __GNUC__ and the like.

Thanks!
Rugxulo

Homepage

Usono,
06.09.2015, 02:32

@ alexfru
 

Smaller C compiler

Post reply

> Smaller C does not support all of the C language (that applies to the
> library as well) and the compiler proper uses a fixed amount of memory to
> keep track of declarations and symbols. It is unlikely that some random
> stuff pulled in from, say, DJGPP include directories (by mistake or
> intentionally) will do much good. So, the location of system headers is
> overridden to prevent mixing and matching system headers, especially while
> having these limitations.
Okay, makes sense, I had forgotten about that possibility.

> > Also, you should probably also use "-U__GNUC__" since some macros may
> > depend on it. If you don't do this and use GCC as preprocessor,
> > SmallerC will choke on faulty code.
>
> Maybe. Right now you can depend on __SMALLER_C__ for stuff that's intended
> for Smaller C and when it's not defined do something else for gcc or
> another compiler. Given the above limitations, you still pretty much have
> to write specialized code for Smaller C, in which case checking first for
> __SMALLER_C__ isn't that much different from checking for __GNUC__ and the
> like.
Well, I'm not sure why I ever (even optionally) used case ranges. It's trivial syntactic sugar, not very useful, the object code isn't any different/better, so I've removed it.

However, my trivial code doesn't need additional checks, everything so far works fine (since you've implemented most stuff already).

Anyways, FYI, I think -undef is more appropriate: "Do not predefine any system-specific or GCC-specific macros. The standard predefined macros remain defined."
alexfru

USA,
06.09.2015, 07:05

@ Rugxulo
 

Smaller C compiler

Post reply

> > Smaller C does not support all of the C language (that applies to the
> > library as well) and the compiler proper uses a fixed amount of memory
> to
> > keep track of declarations and symbols. It is unlikely that some random
> > stuff pulled in from, say, DJGPP include directories (by mistake or
> > intentionally) will do much good. So, the location of system headers is
> > overridden to prevent mixing and matching system headers, especially
> while
> > having these limitations.
>
> Okay, makes sense, I had forgotten about that possibility.
>
> > > Also, you should probably also use "-U__GNUC__" since some macros may
> > > depend on it. If you don't do this and use GCC as preprocessor,
> > > SmallerC will choke on faulty code.
> >
> > Maybe. Right now you can depend on __SMALLER_C__ for stuff that's
> intended
> > for Smaller C and when it's not defined do something else for gcc or
> > another compiler. Given the above limitations, you still pretty much
> have
> > to write specialized code for Smaller C, in which case checking first
> for
> > __SMALLER_C__ isn't that much different from checking for __GNUC__ and
> the
> > like.
>
> Well, I'm not sure why I ever (even optionally) used case ranges. It's
> trivial syntactic sugar, not very useful, the object code isn't any
> different/better, so I've removed it.
>
> However, my trivial code doesn't need additional checks, everything so far
> works fine (since you've implemented most stuff already).
I try not to use any compiler-specific extensions unless absolutely needed in the project.

> Anyways, FYI, I think
> -undef
> is more appropriate: "Do not predefine any system-specific or GCC-specific
> macros. The standard predefined macros remain defined."
I must've missed that option. I should've used it from the beginning. Thanks for mentioning it, I'll add it in one of the future versions.
alexfru

USA,
07.09.2015, 04:14

@ Rugxulo
 

Smaller C compiler

Post reply

> Anyways, FYI, I think
> -undef
> is more appropriate: "Do not predefine any system-specific or GCC-specific
> macros. The standard predefined macros remain defined."
Works with MinGW gcc 4.8.2.

Doesn't work with DJGPP gcc 3.3.4 (no error, but __GNUC__ remains defined). Odd.
Rugxulo

Homepage

Usono,
08.09.2015, 00:48

@ alexfru
 

Smaller C compiler

Post reply

> > Anyways, FYI, I think -undef is more appropriate
>
> Works with MinGW gcc 4.8.2. Doesn't work with DJGPP gcc 3.3.4 (no error,
> but __GNUC__ remains defined). Odd.
DJGPP GCCs 3.4.6 and 4.9.1 worked fine for me. I don't know which versions would be wise to suggest that users rely upon anymore. Maybe 4.7.3 or 5.2.0 since those are latest for 2.03p2 and 2.04 (until 2.05 becomes /current/, which might honestly be any day now, dunno!).
alexfru

USA,
08.09.2015, 01:08

@ Rugxulo
 

Smaller C compiler

Post reply

> > > Anyways, FYI, I think
> -undef
> is more appropriate
> >
> > Works with MinGW gcc 4.8.2. Doesn't work with DJGPP gcc 3.3.4 (no error,
> > but __GNUC__ remains defined). Odd.
>
> DJGPP GCCs 3.4.6 and 4.9.1 worked fine for me. I don't know which versions
> would be wise to suggest that users rely upon anymore. Maybe 4.7.3 or 5.2.0
> since those are latest for 2.03p2 and 2.04 (until 2.05 becomes /current/,
> which might honestly be any day now, dunno!).
Yeah, I haven't updated mine for a long time (10 years?). I'm not doing much DOS programming these days. Anyway, I've included -undef in smlrcc.exe.
Rugxulo

Homepage

Usono,
12.11.2015, 03:02

@ alexfru
 

Smaller C compiler

Post reply

> > DJGPP GCCs 3.4.6 and 4.9.1 worked fine for me. I don't know which
> versions
> > would be wise to suggest that users rely upon anymore. Maybe 4.7.3 or
> 5.2.0
> > since those are latest for 2.03p2 and 2.04 (until 2.05 becomes
> /current/,
> > which might honestly be any day now, dunno!).
DJGPP 2.05 has indeed been officially released into /current/ (replacing both 2.03p2 and /beta/ 2.04), and latest GCC is 5.2.0 (but additionally a few others were also rebuilt: 4.9.3, 4.8.5, 4.7.4, 3.4.6).

> Yeah, I haven't updated mine for a long time (10 years?). I'm not doing
> much DOS programming these days. Anyway, I've included -undef in
> smlrcc.exe.
10 years ago is roughly when the 3.x series ended. I think it's fair to say that even 4.9.3 is barely maintained and will probably be soon dropped (once 4.9.4 and/or 6.0 are released).

Why am I wasting your time with this? Dunno!

P.S. For a laugh, check this out: movfuscator ("The single instruction C compiler")
Oso2k

12.11.2015, 22:59

@ Rugxulo
 

Smaller C compiler

Post reply

> > > DJGPP GCCs 3.4.6 and 4.9.1 worked fine for me. I don't know which
> > versions
> > > would be wise to suggest that users rely upon anymore. Maybe 4.7.3 or
> > 5.2.0
> > > since those are latest for 2.03p2 and 2.04 (until 2.05 becomes
> > /current/,
> > > which might honestly be any day now, dunno!).
>
> DJGPP 2.05 has indeed been officially released into /current/ (replacing
> both 2.03p2 and /beta/ 2.04), and latest GCC is 5.2.0 (but additionally a
> few others were also rebuilt: 4.9.3, 4.8.5, 4.7.4, 3.4.6).
>
> > Yeah, I haven't updated mine for a long time (10 years?). I'm not doing
> > much DOS programming these days. Anyway, I've included -undef in
> > smlrcc.exe.
>
> 10 years ago is roughly when the 3.x series ended. I think it's fair to say
> that even 4.9.3 is barely maintained and will probably be soon dropped
> (once 4.9.4 and/or 6.0 are released).
>
> Why am I wasting your time with this? Dunno!
>
> P.S. For a laugh, check this out:
> movfuscator ("The
> single instruction C compiler")
FYI, gcc 4.8.4 is the current compiler in ubuntu 14.04.3. 4.8.x will likely be a compiler to support for 3 more years (2019/04) as 14.04 was an LTS release, enjoying 5 years total of support by Canonical. In reality, most people will move have moved to 16.04 or 18.04 by 2019.
Rugxulo

Homepage

Usono,
05.12.2015, 06:00

@ Oso2k
 

Smaller C compiler

Post reply

> > 10 years ago is roughly when the 3.x series ended. I think it's fair to say
> > that even 4.9.3 is barely maintained and will probably be soon dropped
> > (once 4.9.4 and/or 6.0 are released).
>
> FYI, gcc 4.8.4 is the current compiler in ubuntu 14.04.3. 4.8.x will likely
> be a compiler to support for 3 more years (2019/04) as 14.04 was an LTS
> release, enjoying 5 years total of support by Canonical. In reality, most
> people will move have moved to 16.04 or 18.04 by 2019.
https://gcc.gnu.org/ml/gcc/2015-12/msg00054.html

"Yes, there will be another 4.9 release as well. Usually we close the 4.9
branch with a last release somewhen after GCC 6 is released."

That was my point, that 4.9.x is basically dead. It's not that some distros won't still use it, but that's not quite what I meant by "supported". There seems to be a mad rush to move to 5.x (and 5.3 was released today, although of course Debian presumably still hasn't migrated everything to 5.x yet).
Rugxulo

Homepage

Usono,
14.06.2016, 03:34

@ alexfru
 

Smaller C compiler

Post reply

It seems that MS Visual C is starting to use a new, improved optimizer.

https://blogs.msdn.microsoft.com/vcblog/2016/05/04/new-code-optimizer/

I mention this only because they mention fuzz testing with tools like Csmith, C-Reduce, Opt-fuzz, etc.

So maybe those tools could help you, too?
alexfru

USA,
14.06.2016, 11:16

@ Rugxulo
 

Smaller C compiler

Post reply

> It seems that MS Visual C is starting to use a new, improved optimizer.
>
> https://blogs.msdn.microsoft.com/vcblog/2016/05/04/new-code-optimizer/
It's probably time. OTOH, they write that they too are now abusing undefined behavior, e.g. signed integer overflows. Seems like they want to be as pseudo-effective as gcc and clang. I wonder how many teams are affected by that and how many have simply decided to disable the "helpful" feature instead of fixing the code. And some code has changed little since Windows 3.xx. Fun! :)

> I mention this only because they mention fuzz testing with tools like
> Csmith, C-Reduce, Opt-fuzz, etc.
>
> So maybe those tools could help you, too?
I know of the first two and it looks like the last one doesn't generate C code. Anyhow, I know most of the issues and I do have a bunch of tests (written by myself, borrowed or generated somewhat similarly to Csmith). The project has accumulated six issues on github in the past three years, of which only one was a bug (in the linker) and the rest were either questions or known/documented issues. There's one build issue on MacOS, the only open issue today. So, either nobody's using the project, or there aren't that many problems in it if people aren't reporting them. So, it looks like I should be OK w.r.t. bugs.

What I really (still!) need is a preprocessor. I like a lot the one from Plan9/LCC because it's complete, proven, small and even compiles as-is (the LCC variant) with Smaller C. I do not like its license, however. Others are either big or bad (rather incomplete, buggy, using functions that aren't in the C standard).
Rugxulo

Homepage

Usono,
15.06.2016, 01:00

@ alexfru
 

Smaller C compiler

Post reply

> > I mention this only because they mention fuzz testing with tools like
> > Csmith, C-Reduce, Opt-fuzz, etc.
> >
> > So maybe those tools could help you, too?
>
> I know most of the issues and I do have a bunch of tests ...
> So, either nobody's using the project,
Sadly, some people have no imagination, certainly regarding DOS.

> or there aren't that many problems in it if people aren't reporting them.
Right, I didn't see any obvious errors. But my usage was far from expert anyways. Still, I've seen much worse compilers.

> So, it looks like I should be OK w.r.t. bugs.
Yes, I think you've already ironed out most obvious bugs. I just felt like mentioning it in the off chance that it would help iron out some more hidden cases (since no software is ever totally bug-free).

> What I really (still!) need is a preprocessor. I like a lot the one from
> Plan9/LCC because it's complete, proven, small and even compiles as-is (the
> LCC variant) with Smaller C. I do not like its license, however. Others are
> either big or bad (rather incomplete, buggy, using functions that aren't in
> the C standard).
Isn't ancient GCC 2.7's CPP fairly small? I imagine that would be (relatively) easy to port.

As for Plan9 license, what is wrong with it? AFAIK, it has changed several times, so it should be okay. Heck, I think they even dual-licensed to GPL recently.

Wikipedia says this:

> Starting with the release of Fourth edition on April 2002,
> the full source code of Plan 9 from Bell Labs was freely
> available under Lucent Public License 1.02, which is considered
> to be open source license by the Open Source Initiative (OSI),
> free software license by the Free Software Foundation, and it
> passes the Debian Free Software Guidelines.
 >
> In February 2014, the University of California, Berkeley, has
> been authorized by the current Plan 9 copyright holder ?
> Alcatel-Lucent ? to release all Plan 9 software previously
> governed by the Lucent Public License, Version 1.02 under the
> GNU General Public License, Version 2.
You mention Plan9/LCC, but isn't LCC different? Plan9 has its own compiler. Though LCC does allegedly use dmr's CPP (or so I thought). Yeah, LCC license sucks.

I would even suggest (T)ACK, but I don't see a separate CPP binary there.
But it's BSD-ish and relatively simple. Maybe (BSD-ish) PCC? Theirs seems fairly small. Or even BCC/Dev86? Meh, dunno.
alexfru

USA,
15.06.2016, 09:11

@ Rugxulo
 

Smaller C compiler

Post reply

> > > I mention this only because they mention fuzz testing with tools like
> > > Csmith, C-Reduce, Opt-fuzz, etc.
> > >
> > > So maybe those tools could help you, too?
> >
> > I know most of the issues and I do have a bunch of tests ...
> > So, either nobody's using the project,
>
> Sadly, some people have no imagination, certainly regarding DOS.
My compiler targets Windows, Linux and RetroBSD as well, so, it's either the compiler or all four OSes. :)

> > or there aren't that many problems in it if people aren't reporting
> them.
>
> Right, I didn't see any obvious errors. But my usage was far from expert
> anyways. Still, I've seen much worse compilers.
>
> > So, it looks like I should be OK w.r.t. bugs.
>
> Yes, I think you've already ironed out most obvious bugs. I just felt like
> mentioning it in the off chance that it would help iron out some more
> hidden cases (since no software is ever totally bug-free).
>
> > What I really (still!) need is a preprocessor. I like a lot the one from
> > Plan9/LCC because it's complete, proven, small and even compiles as-is
> (the
> > LCC variant) with Smaller C. I do not like its license, however. Others
> are
> > either big or bad (rather incomplete, buggy, using functions that aren't
> in
> > the C standard).
>
> Isn't ancient GCC 2.7's CPP fairly small? I imagine that would be
> (relatively) easy to port.
I haven't seen it, but I have doubts.

> As for Plan9 license, what is wrong with it? AFAIK, it has changed several
> times, so it should be okay. Heck, I think they even dual-licensed to GPL
> recently.
>
> Wikipedia says this:
>
> > Starting with the release of Fourth edition on April 2002,
> > the full source code of Plan 9 from Bell Labs was freely
> > available under Lucent Public License 1.02, which is considered
> > to be open source license by the Open Source Initiative (OSI),
> > free software license by the Free Software Foundation, and it
> > passes the Debian Free Software Guidelines.
> >
> > In February 2014, the University of California, Berkeley, has
> > been authorized by the current Plan 9 copyright holder ?
> > Alcatel-Lucent ? to release all Plan 9 software previously
> > governed by the Lucent Public License, Version 1.02 under the
> > GNU General Public License, Version 2.
I didn't know about that. I have plan9.iso.bz2 downloaded in January 2015 from Lucent. It contains some files dated May 2014 (May > February!) and its only mention of GPL is with respect to printer fonts. Most of the thing is under Lucent Public License, Version 1.02 in there.

> You mention Plan9/LCC, but isn't LCC different? Plan9 has its own compiler.
The compiler proper is different. But the LCC authors borrowed the preprocessor from Plan9 and made a few relatively small changes (mostly cleaned it up and made ANSI C). In their LCC book they don't even describe the preprocessor, only mention its existence.

> Though LCC does allegedly use dmr's CPP (or so I thought). Yeah, LCC
> license sucks.
I wonder if the LCC guys would agree to explicitly license their version of the preprocessor as GPL as well (they don't have to, but it would be nice = less work for me or for someone else adapting the code again).

> I would even suggest (T)ACK, but I don't see a separate CPP binary there.
There was something I didn't like about ACK.

> But it's BSD-ish and relatively simple. Maybe (BSD-ish) PCC? Theirs seems
> fairly small.
It is. We use it in RetroBSD, but it has a few odd problems w.r.t. memory management / memory use. It also makes use of lex/yacc/whatever, which I'm not happy about either.

> Or even BCC/Dev86? Meh, dunno.
I wouldn't go there.
Rugxulo

Homepage

Usono,
16.06.2016, 19:26

@ alexfru
 

Smaller C compiler

Post reply

> > > What I really (still!) need is a preprocessor.
>
> > You mention Plan9/LCC, but isn't LCC different? Plan9 has its own
> compiler.
>
> The compiler proper is different. But the LCC authors borrowed the
> preprocessor from Plan9
Ah, I had forgotten (since I've never used Plan9) that they were a bit different. So yeah, perhaps by default they didn't need (or want) a "full" preprocessor, hence the POSIX environment add-on.

> > Though LCC does allegedly use dmr's CPP (or so I thought). Yeah, LCC
> > license sucks.
>
> I wonder if the LCC guys would agree to explicitly license their version of
> the preprocessor as GPL as well (they don't have to, but it would be nice =
> less work for me or for someone else adapting the code again).
Like I said, Plan9 is dual-licensed these days, so maybe it already is okay. But maybe not. Hopefully so, but then again, if LCC itself still (!) isn't OSI or FSF friendly, then it's unlikely they'll ever care.

Besides, if dmr had copyright on his cpp (and not AT&T or whomever), then you might be out of luck (since he died and copyright is notoriously broken regarding re-licensing after-the-fact).

> > I would even suggest (T)ACK, but I don't see a separate CPP binary
> there.
>
> There was something I didn't like about ACK.
Well, if the cpp isn't a separate utility, it's probably useless for your needs. But that one guy did finally make a new pre-release a week or so ago. The big change now is using ordinary makefiles (instead of Prime Mover [Lua]), maybe that's what you meant??

AFAIK, cpp evolved from m4, m3, and Kernighan's "macro" (Software Tools??). Though somehow I doubt any of those would help you much either. It can't be THAT hard (famous last words)!
alexfru

USA,
17.06.2016, 10:36

@ Rugxulo
 

Smaller C compiler

Post reply

> > > > What I really (still!) need is a preprocessor.
> >
> > > You mention Plan9/LCC, but isn't LCC different? Plan9 has its own
> > compiler.
> >
> > The compiler proper is different. But the LCC authors borrowed the
> > preprocessor from Plan9
>
> Ah, I had forgotten (since I've never used Plan9) that they were a bit
> different. So yeah, perhaps by default they didn't need (or want) a "full"
> preprocessor, hence the POSIX environment add-on.
I'm not sure what you're talking about. There's not much of POSIX in the preprocessor, just file handles and open()/read()/etc instead of FILE* and fopen()/fgetc()/etc, which is the easiest thing to clean up and standardize w.r.t. ANSI C. In terms of functionality there's almost no difference as far as I can tell by looking at the diff (most notably, wide chars, Unicode and variadic macros (..., __VA_ARGS__) have been removed). But it looks like they've done some valuable cleanup as well.

> > > Though LCC does allegedly use dmr's CPP (or so I thought). Yeah, LCC
> > > license sucks.
> >
> > I wonder if the LCC guys would agree to explicitly license their version
> of
> > the preprocessor as GPL as well (they don't have to, but it would be nice
> =
> > less work for me or for someone else adapting the code again).
>
> Like I said, Plan9 is dual-licensed these days, so maybe it already is
> okay. But maybe not. Hopefully so, but then again, if LCC itself still (!)
> isn't OSI or FSF friendly, then it's unlikely they'll ever care.
I don't think licenses can travel backwards and then forward again in time. The diff between LCC and Plan9 is not GPL'd.

> > > I would even suggest (T)ACK, but I don't see a separate CPP binary
> > there.
> >
> > There was something I didn't like about ACK.
>
> Well, if the cpp isn't a separate utility, it's probably useless for your
> needs. But that one guy did finally make a new pre-release a week or so
> ago. The big change now is using ordinary makefiles (instead of Prime Mover
> [Lua]), maybe that's what you meant??
Nopes. Just looked at it again. It needs additional tools to compile besides the C compiler.

Alex
Rugxulo

Homepage

Usono,
18.06.2016, 18:26

@ alexfru
 

Smaller C compiler

Post reply

> > Ah, I had forgotten (since I've never used Plan9) that they were a bit
> > different. So yeah, perhaps by default they didn't need (or want) a
> > "full" preprocessor, hence the POSIX environment add-on.
>
> I'm not sure what you're talking about.
http://man.cat-v.org/plan_9/1/cpp

"The standard Plan 9 C compilers do not use cpp; they contain their own simple but adequate preprocessor, so cpp is usually superfluous."

http://plan9.bell-labs.com/sys/doc/comp.html

"The compilers include an integrated preprocessor that accepts the familiar #include, #define for macros both with and without arguments, #undef, #line, #ifdef, #ifndef, and #endif. It supports neither #if nor ##, although it does honor a few #pragmas. The #if directive was omitted because it greatly complicates the preprocessor, is never necessary, and is usually abused. Conditional compilation in general makes code hard to understand; the Plan 9 source uses it sparingly. Also, because the compilers remove dead code, regular if statements with constant conditions are more readable equivalents to many #ifs. To compile imported code ineluctably fouled by #if there is a separate command, /bin/cpp, that implements the complete ANSI C preprocessor specification."

> I don't think licenses can travel backwards and then forward again in time.
> The diff between LCC and Plan9 is not GPL'd.
How big a difference (and advantage) is it? Surely you can handle the original (worse code but better license).
alexfru

USA,
19.06.2016, 00:08

@ Rugxulo
 

Smaller C compiler

Post reply

> > > Ah, I had forgotten (since I've never used Plan9) that they were a bit
> > > different. So yeah, perhaps by default they didn't need (or want) a
> > > "full" preprocessor, hence the POSIX environment add-on.
> >
> > I'm not sure what you're talking about.
>
> http://man.cat-v.org/plan_9/1/cpp
>
> "The standard Plan 9 C compilers do not use cpp; they contain their own
> simple but adequate preprocessor, so cpp is usually superfluous."
>
> http://plan9.bell-labs.com/sys/doc/comp.html
>
> "The compilers include an integrated preprocessor that accepts the familiar
> #include, #define for macros both with and without arguments, #undef,
> #line, #ifdef, #ifndef, and #endif. It supports neither #if nor ##,
> although it does honor a few #pragmas. The #if directive was omitted
> because it greatly complicates the preprocessor, is never necessary, and is
> usually abused. Conditional compilation in general makes code hard to
> understand; the Plan 9 source uses it sparingly. Also, because the
> compilers remove dead code, regular if statements with constant conditions
> are more readable equivalents to many #ifs. To compile imported code
> ineluctably fouled by #if there is a separate command, /bin/cpp, that
> implements the complete ANSI C preprocessor specification."
I've read all that before. However, I've missed or forgotten the statement "The compilers include an integrated preprocessor", which may explain certain issues (bugs, etc) in their standalone preprocessor. They simply didn't care much about it and it somehow worked for them in those rare cases they needed it.

As for "perhaps by default they didn't need (or want) a "full" preprocessor, hence the POSIX environment add-on", #if and ## are standard in C and not specific to POSIX. This is why I wasn't sure what you meant.

> > I don't think licenses can travel backwards and then forward again in
> time.
> > The diff between LCC and Plan9 is not GPL'd.
>
> How big a difference (and advantage) is it? Surely you can handle the
> original (worse code but better license).
The diff is not too big or complex, but I'll have to review it because it seems to also fix a few issues. Right now I'm cleaning up and ANSI-C-fying the original code (duplicate work), so it can compile with a standard compiler and minimally function. Then I'll make further fixes and improvements with a few specific for Smaller C.

Alex
Rugxulo

Homepage

Usono,
19.06.2016, 01:56

@ alexfru
 

Smaller C compiler

Post reply

> I've read all that before. However, I've missed or forgotten the statement
> "The compilers include an integrated preprocessor", which may explain
> certain issues (bugs, etc) in their standalone preprocessor. They simply
> didn't care much about it and it somehow worked for them in those rare
> cases they needed it.
>
> As for "perhaps by default they didn't need (or want) a "full"
> preprocessor, hence the POSIX environment add-on", #if and ## are standard
> in C and not specific to POSIX. This is why I wasn't sure what you meant.
Even though I've never used it, I was referring to this:

APE ? The ANSI/POSIX Environment
Oso2k

04.07.2016, 07:22

@ Rugxulo
 

Smaller C compiler

Post reply

If you're not a fan of that other ucpp, you can try my copy which is minimally changed from Thomas P's version (make file only, a couple bug fixes, easy to embed). Btw, I'm the upstream the other ucpp links to on code.google.com.

https://github.com/lpsantil/ucpp
alexfru

USA,
10.07.2016, 08:19

@ Oso2k
 

Smaller C compiler

Post reply

> If you're not a fan of that other ucpp, you can try my copy which is
> minimally changed from Thomas P's version (make file only, a couple bug
> fixes, easy to embed). Btw, I'm the upstream the other ucpp links to on
> code.google.com.
>
> https://github.com/lpsantil/ucpp
I've actually almost finished integrating it with Smaller C. You can get the work-in-progress from a temporary branch, ucpp (will disappear once merged into master). It seems to be working.
Rugxulo

Homepage

Usono,
30.07.2016, 07:20

@ alexfru
 

Smaller C compiler

Post reply

> I've actually almost finished integrating it with Smaller C.
> It seems to be working.
Nice work! Good job! :ok:
alexfru

USA,
30.07.2016, 07:54

@ Rugxulo
 

Smaller C compiler

Post reply

> > I've actually almost finished integrating it with Smaller C.
> > It seems to be working.
>
> Nice work! Good job! :ok:
Thanks! :)
Rugxulo

Homepage

Usono,
09.08.2016, 18:40
(edited by Rugxulo, 09.08.2016, 20:38)

@ alexfru
 

Smaller C compiler

Post reply

BTW, I've never looked closely, but I'm not sure your tmpfile handling works correctly in FreeDOS. It doesn't seem to find %TEMP% or %TMP%, instead preferring current dir (e.g. "@.\TMP00002.$$$").

Even worse, although I admit this is an extremely rare scenario, when I boot up my old P4 (using PLoP Boot Manager), there is no real hard disk, thus "C:\" is (read-only) USB, which of course confuses smlrcc (despite %TEMP%, %TMP%, %TMPDIR% pointing to RAM disk!!), causing a critical error.

(Honestly, I don't know, this could be some rare FreeDOS bug/compatibility quirk. I vaguely remember some weirdness in findfirst re: dirs.)

Maybe "-tmpdir" option to override auto-detection would be easier?

EDIT: "g:" and "g:\" both work okay, but (default) "g:\temp" doesn't (nor do several other variations), if that helps narrow things down.
alexfru

USA,
10.08.2016, 09:38

@ Rugxulo
 

Smaller C compiler

Post reply

> BTW, I've never looked closely, but I'm not sure your tmpfile handling
> works correctly in FreeDOS. It doesn't seem to find %TEMP% or %TMP%,
> instead preferring current dir (e.g. "@.\TMP00002.$$$").
>
> Even worse, although I admit this is an extremely rare scenario, when I
> boot up my old P4 (using PLoP Boot Manager), there is no real hard disk,
> thus "C:\" is (read-only) USB, which of course confuses smlrcc (despite
> %TEMP%, %TMP%, %TMPDIR% pointing to RAM disk!!), causing a critical error.
>
> (Honestly, I don't know, this could be some rare FreeDOS bug/compatibility
> quirk. I vaguely remember some weirdness in findfirst re: dirs.)
I'll take a look later this week.

> Maybe "-tmpdir" option to override auto-detection would be easier?
I don't think this should be needed once the issue is understood and resolved.

> EDIT: "g:" and "g:\" both work okay, but (default) "g:\temp" doesn't (nor
> do several other variations), if that helps narrow things down.
What do you mean by that? Are you saying that setting TEMP=g:\ or TEMP=g: works, while TEMP=g:\temp doesn't?
alexfru

USA,
10.08.2016, 13:40

@ Rugxulo
 

Smaller C compiler

Post reply

> BTW, I've never looked closely, but I'm not sure your tmpfile handling
> works correctly in FreeDOS. It doesn't seem to find %TEMP% or %TMP%,
It turns out I'd messed up slashes when passing paths to function 0x4300 to see if %TEMP% exists as a directory. C:\ and C:\FOO are OK, but C: and C:\FOO\ are not. Since I always had writable C: with enough space and on Windows smlrcc does not invoke tmpfile(), I never saw the problem. It's also possible that Windows and/or DOSBox was too forgiving when I looked at this some time ago and saw no obvious problem.

Try the updated binaries and libraries.
Rugxulo

Homepage

Usono,
10.08.2016, 16:40

@ alexfru
 

Smaller C compiler

Post reply

> Try the updated binaries and libraries.
Some quick testing under VM (FreeDOS) shows that it works okay now.
Rugxulo

Homepage

Usono,
19.08.2016, 03:10

@ alexfru
 

Smaller C compiler

Post reply

(This is almost too trivial or redundant to even mention, but alas ....)

Your main Github page points to this (now broken) link:

CWSDPMI: http://homer.rice.edu/~sandmann/cwsdpmi/

But you can still find it on DJGPP mirrors under /current/v2misc/ .

It's also recently been mirrored on iBiblio for FreeDOS.

Another related issue is your wiki section regarding this:

> -maxheap <number> Specifies the maximum heap size (in bytes)
> for DPMI programs. To be used with option -dosp. If the option isn't
> given, the linker assumes 16777216 (16MB). The number can be decimal,
> hex or octal. The program may receive a heap whose size is smaller
> than this number (e.g. if there isn't this much free DPMI memory;
> Windows XP can provide up to ~1GB of DPMI memory while Windows Vista/7
> is known to limit DPMI memory to 16MB).
I haven't used 32-bit Windows in several years, since my Vista laptop died, but AFAIK the limit was (default) 32 MB, only adjustable (with SP1) with a registry hack. "Add registry entry 'DpmiLimit' with large enough
value to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW ".
alexfru

USA,
19.08.2016, 08:55

@ Rugxulo
 

Smaller C compiler

Post reply

> (This is almost too trivial or redundant to even mention, but alas ....)
>
> Your main Github page points to this (now broken) link:
>
> CWSDPMI: http://homer.rice.edu/~sandmann/cwsdpmi/
The entire homer isn't accessible. Odd.

> But you can still find it on DJGPP mirrors under
> /current/v2misc/
> .
>
> It's also recently been mirrored on
> iBiblio
> for FreeDOS.
Yeah, I can link to e.g. DJGPP's servers.

> Another related issue is your wiki section regarding this:
>
> > -maxheap <number> Specifies the maximum heap size (in bytes)
> > for DPMI programs. To be used with option -dosp. If the option isn't
> > given, the linker assumes 16777216 (16MB). The number can be decimal,
> > hex or octal. The program may receive a heap whose size is smaller
> > than this number (e.g. if there isn't this much free DPMI memory;
> > Windows XP can provide up to ~1GB of DPMI memory while Windows Vista/7
> > is known to limit DPMI memory to 16MB).
>
> I haven't used 32-bit Windows in several years, since my Vista laptop died,
> but AFAIK the limit was (default) 32 MB, only adjustable (with SP1) with a
> registry hack. "Add registry entry 'DpmiLimit' with large enough
> value to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW
> ".
It's probably a typo (I want to check with my 32-bit Windows 7). I was probably thinking of DOSBox at the time or about the -maxheap default.
alexfru

USA,
28.08.2016, 08:46

@ alexfru
 

Smaller C compiler

Post reply

> > (This is almost too trivial or redundant to even mention, but alas ....)
> >
> > Your main Github page points to this (now broken) link:
> >
> > CWSDPMI: http://homer.rice.edu/~sandmann/cwsdpmi/
>
> The entire homer isn't accessible. Odd.
>
> > But you can still find it on DJGPP mirrors under
> >
> /current/v2misc/
> > .
> >
> > It's also recently been mirrored on
> >
> iBiblio
> > for FreeDOS.
>
> Yeah, I can link to e.g. DJGPP's servers.
I wrote an e-mail to the author to see if he's going to upload it anywhere else. Mentioned github.

> > Another related issue is your wiki section regarding this:
> >
> > > -maxheap <number> Specifies the maximum heap size (in bytes)
> > > for DPMI programs. To be used with option -dosp. If the option isn't
> > > given, the linker assumes 16777216 (16MB). The number can be decimal,
> > > hex or octal. The program may receive a heap whose size is smaller
> > > than this number (e.g. if there isn't this much free DPMI memory;
> > > Windows XP can provide up to ~1GB of DPMI memory while Windows Vista/7
> > > is known to limit DPMI memory to 16MB).
> >
> > I haven't used 32-bit Windows in several years, since my Vista laptop
> died,
> > but AFAIK the limit was (default) 32 MB, only adjustable (with SP1) with
> a
> > registry hack. "Add registry entry 'DpmiLimit' with large enough
> > value to
> Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW
> > ".
>
> It's probably a typo (I want to check with my 32-bit Windows 7). I was
> probably thinking of DOSBox at the time or about the -maxheap default.
Just checked, indeed 32MB is the default DPMI max under Windows 7. The number is updated, thanks!
alexfru

USA,
14.12.2016, 08:50

@ alexfru
 

Smaller C compiler

Post reply

> > >
> > > Your main Github page points to this (now broken) link:
> > >
> > > CWSDPMI: http://homer.rice.edu/~sandmann/cwsdpmi/
> >
> > The entire homer isn't accessible. Odd.
> >
> > > But you can still find it on DJGPP mirrors under
> > >
> >
> /current/v2misc/
> > > .
> > >
> > > It's also recently been mirrored on
> > >
> >
> iBiblio
> > > for FreeDOS.
> >
> > Yeah, I can link to e.g. DJGPP's servers.
>
> I wrote an e-mail to the author to see if he's going to upload it anywhere
> else. Mentioned github.
Just got an e-mail from Charles:

----8<----
http://sandmann.dotster.com/index1.html
http://sandmann.dotster.com/cwsdpmi/

(I am working on a nicer DNS / redirect)

I have just been exceptionally busy. This will also restore the win2k pages and some other things I have provided in the past. Perhaps we should consider what is really important and also mirror on DJ?s server.

BTW, my EarthLink email addresses are probably dying end of this month, so I need to set up a replacement on one of my domains (but I need to change about 200 email pointers first).
----8<----

So, things may change again.
Rugxulo

Homepage

Usono,
14.05.2017, 22:29

@ alexfru
 

Smaller C compiler

Post reply

> news://comp.os.msdos.programmer on Wed 07 Sep 2016
>
> I don't remember if my compiler's output assembles with
> jump optimization disabled. It might not. I know that
> old versions of NASM used not to assemble it because by
> default NASM would not extend conditional jumps beyond
> the short -128/+127 range.
Yes, if "cpu 8086" is used, even with -O0, it will still workaround this architectural limit with two jumps behind the scenes.

But does your compiler need 8086? I thought it was 386+ only? You don't have such range limits in 386 jumps.

So I have no idea if you can speed up your tests by "set NASMENV=-O0" or not. Try it and see. At least one of my simple programs still compiled and ran okay with -O0.
alexfru

USA,
17.05.2017, 08:33

@ Rugxulo
 

Smaller C compiler

Post reply

> > news://comp.os.msdos.programmer on Wed 07 Sep 2016
> >
> > I don't remember if my compiler's output assembles with
> > jump optimization disabled. It might not. I know that
> > old versions of NASM used not to assemble it because by
> > default NASM would not extend conditional jumps beyond
> > the short -128/+127 range.
>
> Yes, if "cpu 8086" is used, even with -O0, it will still workaround this
> architectural limit with two jumps behind the scenes.
>
> But does your compiler need 8086? I thought it was 386+ only? You don't
> have such range limits in 386 jumps.
It is 386+ only. But *old* NASM wouldn't assemble the compiler output.

> So I have no idea if you can speed up your tests by "set NASMENV=-O0" or
> not. Try it and see. At least one of my simple programs still compiled and
> ran okay with -O0.
It helps a tiny bit.

Compiling main compiler file for Windows under Windows:

Using NASM (the default; no NASMENV):
smlrcc -c smlrc.c
8 seconds

Using NASM (the default; NASMENV=-O0):
smlrcc -c smlrc.c
5 seconds

Using YASM:
smlrcc -c smlrc.c -asm yasm
1 second

Using FASM + n2f:
smlrcc -c smlrc.c -asm n2f
1 second

The difference between assemblers is huge as you can see.
Rugxulo

Homepage

Usono,
18.06.2017, 07:47

@ alexfru
 

Smaller C compiler

Post reply

> > So I have no idea if you can speed up your tests by "set NASMENV=-O0"
>
> It helps a tiny bit.
So what about using "-a"? I haven't tested it, but they claim its
faster:

http://www.nasm.us/xdoc/2.13.01/html/nasmdoc2.html#section-2.1.21

> If NASM is being used as the back end to a compiler, it might
> be desirable to suppress preprocessing completely and assume
> the compiler has already done it, to save time and increase
> compilation speeds. The -a option, requiring no argument,
> instructs NASM to replace its powerful preprocessor with a
> stub preprocessor which does nothing.
Rugxulo

Homepage

Usono,
18.06.2017, 20:31

@ Rugxulo
 

Smaller C compiler

Post reply

> So what about using "-a"? I haven't tested it, but they claim its
> faster:
No, it won't work ... by default, without minor fixes:

http://www.nasm.us/xdoc/2.13.01/html/nasmdoc6.html

> Primitive directives are enclosed in square brackets;
> user-level directives are not.
So "bits", "section", "global", "extern", etc. need to be surrounded by square brackets, e.g. "[bits 16]" in order for "-a" to not error out.

Then it seems to assemble identically to before.
Rugxulo

Homepage

Usono,
10.11.2017, 04:16

@ alexfru
 

Smaller C compiler

Post reply

Someone on freedos-user was mentioning DeSmet C (which was GPL'd several years ago), hinting that we should make a package for FDNPKG. But it's a somewhat limited toolset, and I think SmallerC would make a better package. Would that be okay with you if I made one? It would go in the Software List under Development, mirrored on iBiblio.

In other news, looks like GCC 8 will support "bugfixed" C17.

In still other news, the OpenWatcom 2.0-pre snapshot has been updated very recently.

In annoying (but unsurprising) news, VirusTotal claims to find a trojan in your Win32 PE/.EXE files (under binw). Actually, MS Security Essentials deleted my local .ZIP while I was just listing the files in it! So I had to go to "Settings" and add it to "Excluded files and locations". It's all too common with "exotic" PE/.EXE files.
alexfru

USA,
10.11.2017, 05:27

@ Rugxulo
 

Smaller C compiler

Post reply

> Someone on freedos-user was mentioning DeSmet
> C (which was GPL'd several years ago), hinting that we should make a
> package for
> FDNPKG.

There's also "Pacific C for MS-DOS, v7.51" in case it's forgotten.

> But it's a somewhat limited toolset, and I think SmallerC would
> make a better package. Would that be okay with you if I made one? It would
> go in the Software List under
> Development,
> mirrored on iBiblio.
Include the project GitHub URL and the SHA of the top commit somewhere in the package description, so the package can be traced back if needed as I don't maintain a version in the binaries. Also, it's probably a good idea to include the project wiki pages into the package since there's no /? or --help option in the binaries and somehow those wiki pages are not really part of the project (you don't get them in the .zip file downloaded from gitHub or if you do "git pull" on the project).

> In other news, looks like GCC 8 will support "bugfixed"
> C17.
>
> In still other news, the OpenWatcom 2.0-pre
> snapshot
> has been updated very recently.
>
> In annoying (but unsurprising) news,
> VirusTotal
> claims to find a trojan in your Win32 PE/.EXE files (under binw).
Imbeciles. So much for all the AI/ML/etc hype.

> Actually,
> MS Security Essentials deleted my local .ZIP while I was just listing the
> files in it! So I had to go to "Settings" and add it to "Excluded files and
> locations". It's all too common with "exotic" PE/.EXE files.
Um... I had the project directory excluded on my Windows 7 because it was slowing things down, but I just removed the exclusion and scanned the directory with Security Essentials and all was OK. The virus/malware definitions were last updated yesterday (version 1.257.257.0). What's on your end?
Rugxulo

Homepage

Usono,
11.11.2017, 06:51

@ alexfru
 

Smaller C compiler

Post reply

> There's also "Pacific C for MS-DOS, v7.51" in case it's forgotten.
I've used it, but I suspect OpenWatcom is better. Then again, you found some "scary" bugs (IIRC), so maybe you think otherwise.

> > But it's a somewhat limited toolset, and I think SmallerC would
> > make a better package. Would that be okay with you if I made one?
> > It would go in the Software List under Development, mirrored on iBiblio.
>
> Include the project GitHub URL and the SHA of the top commit somewhere in
> the package description, so the package can be traced back if needed as I
> don't maintain a version in the binaries.
Sounds reasonable.

> Also, it's probably a good idea to include the project wiki pages
> into the package since there's no /? or --help option in the binaries
> and somehow those wiki pages are not really part of the project
> (you don't get them in the .zip file downloaded from gitHub
Sounds tedious, but I'll try (maybe).

> > In annoying (but unsurprising) news, VirusTotal claims to find
> a trojan in your Win32 PE/.EXE files (under binw).
>
> Imbeciles. So much for all the AI/ML/etc hype.
I've had this problem over a dozen times over the years with various tools. It's just bad heuristics, overzealous detection of anything atypical.

> > Actually, MS Security Essentials deleted my local .ZIP
> while I was just listing the files in it! So I had to go to
> "Settings" and add it to "Excluded files and locations".
>
> Um... I had the project directory excluded on my Windows 7 because it was
> slowing things down, but I just removed the exclusion and scanned the
> directory with Security Essentials and all was OK. The virus/malware
> definitions were last updated yesterday (version 1.257.257.0). What's on
> your end?
I'm on the wrong machine right now, but I did update the definitions yesterday. But I'm not imagining this, it definitely deleted it, ugh. Even after having similar problems like this, it's still annoying.

On this machine, I don't have that installed, only Avast, and even it whines, even after updating. So I just now reported your .ZIP as false positive, hoping they'll fix their error (and maybe it will propagate to other databases).

If it makes you feel any better, out of morbid curiosity, I also submitted an innocuous .ZIP of mine to VirusTotal, and it claimed to find ".BAT viruses" (when really they were just analogous to simple shell scripts using sed). :-P
Rugxulo

Homepage

Usono,
12.11.2017, 01:39

@ Rugxulo
 

Smaller C compiler

Post reply

> On this machine, I don't have that installed, only Avast, and even it
> whines
Even old Firefox on this ancient Puppy Linux is whining, so I had to manually "Unblock" just to download it from Github.

Just as an experiment, I changed the useless "cannot be run in DOS" stub message in one PE/.EXE, and that reduced some (but not all) warnings. So that's how stupid some of them are, even changing something simple like useless text avoids "detection". The obvious red flags (to us) are claims of "generic" or "heuristic", which are often bogus.
alexfru

USA,
12.11.2017, 12:07

@ Rugxulo
 

Smaller C compiler

Post reply

> > On this machine, I don't have that installed, only Avast, and even it
> > whines
>
> Even old Firefox on this ancient Puppy Linux is whining, so I had to
> manually "Unblock" just to download it from Github.
>
> Just as an experiment, I changed the useless "cannot be run in DOS" stub
> message in one PE/.EXE, and that reduced some (but not all) warnings. So
> that's how stupid some of them are, even changing something simple like
> useless text avoids "detection". The obvious red flags (to us) are claims
> of "generic" or "heuristic", which are often bogus.
I just recompiled the five executables with OW 1.9 and mingw (gcc 4.8.2) and the results are significantly better:
OW
mingw

This doesn't tell us what it is that that stupid virusware doesn't like. MZ stub? Date/time stamp? Zero checksum? Linker version? Stack & heap sizes? PE header size? Lack of imports from the brain-dead msvcrt.dll? Import entries in .data instead of a section of their own? And there's no guarantee this problem won't come up again even if the format changes to please the virusware of today.
alexfru

USA,
12.11.2017, 12:16

@ alexfru
 

Smaller C compiler

Post reply

> virusware of today.
Rather, scareware.
Rugxulo

Homepage

Usono,
22.11.2017, 06:43

@ Rugxulo
 

Smaller C compiler

Post reply

> On this machine, I don't have that installed, only Avast, and even it
> whines, even after updating. So I just now reported your .ZIP as false
> positive, hoping they'll fix their error (and maybe it will propagate to
> other databases).
(I hate to pollute your thread with this, it's almost off-topic.)

<rant>

Sadly, they still haven't fixed their false detection. At least, "Reanalyze" on VirusTotal still shows Avast as saying "Win32:Malware-gen" (where presumably "gen" means "generic", aka heuristic/guess). 12 days later, sigh.

Maybe I shouldn't complain. It's a thankless job, there are thousands of new malwares coming out every day. Plus, I don't pay for this antivirus, it's freeware. So it's not like it's an easy job or anything special I deserve.

But this situation sucks. If you're going to flag with buggy heuristics (which I don't recommend, for obvious reasons), you have to be somewhat diligent in fixing false positives.

</rant>

On the bright side (sarcasm), even rr's (Win32) UPXDUMP.EXE is apparently suspicious to Avast. Here I was naive and thought it was too vanilla to flag, but nope! I should've known after all the other false positives I've gotten over the years. I know it's typical Internet blowhard to rant and say, "I'm uninstalling!", but maybe that would be best. There's only so many exceptions you can make before the whole thing is more of a nuisance than a solution.

Actually, the simplest answer is: Settings, Enable CyberCapture, change from "always block it" to "allow me to decide". (It previously said it sent it to the labs for analysis, but I have low expectations.)
alexfru

USA,
22.11.2017, 07:58

@ Rugxulo
 

Smaller C compiler

Post reply

> > On this machine, I don't have that installed, only Avast, and even it
> > whines, even after updating. So I just now reported your .ZIP as false
> > positive, hoping they'll fix their error (and maybe it will propagate to
> > other databases).
>
> (I hate to pollute your thread with this, it's almost off-topic.)
>
> <rant>
>
> Sadly, they still haven't fixed their false detection. At least,
> "Reanalyze" on VirusTotal still shows Avast as saying "Win32:Malware-gen"
> (where presumably "gen" means "generic", aka heuristic/guess). 12 days
> later, sigh.
>
...
> </rant>
> ...
I've spent a few hours playing with:
- MZ header (used the ones from mingw and OW)
- PE header meta info (versions from mingw and OW, different time stamp)
- PE header size (set to more common 1024 instead of 4096 and saving 3KB in total size)
and nothing helped.

For a good measure I also uploaded to virustotal a few tiny windows apps that come with FASM and, oh horrors, even those tiny "hello world"-style apps were flagged as malicious by a few engines.

I don't know exactly what's so suspicious about my compiler's output.
One thing I thought was simply poor, unoptimized code with too many memory accesses. Like something that could be automatically generated (duh, that's what compilers do!). But then the same problem would exist in the Linux and MacOS executables. Do those engines not check those other formats at all? Or are there too few viruses for Linux and MacOS?

I have yet to make a few more experiments. Like, compile with gcc but link with smlrl. I should also try Belard's TinyCC as well since it's about as crappy as my compiler in terms of optimization.

I also didn't rule out lack of imports from msvcrt.dll. It must not matter. But it may.
alexfru

USA,
22.11.2017, 08:22

@ alexfru
 

Smaller C compiler

Post reply

> I should also try Belard's TinyCC as well since it's about as
> crappy as my compiler in terms of optimization.
TinyCC is as good as OW above, not perfect though.
alexfru

USA,
22.11.2017, 09:34

@ alexfru
 

Smaller C compiler

Post reply

> I also didn't rule out lack of imports from msvcrt.dll. It must not matter.
> But it may.
Inclusion of some 50 dummy imports from msvcrt.dll moves the needle a tiny bit: from ...
to. Avast is still there with its suspicions.
alexfru

USA,
23.11.2017, 10:20

@ alexfru
 

Smaller C compiler

Post reply

> Avast is still there with its suspicions.
Found this: Report a false detection. Submitted the project URL. We'll see what happens.
Rugxulo

Homepage

Usono,
26.11.2017, 13:43

@ alexfru
 

Smaller C compiler

Post reply

> I don't know exactly what's so suspicious about my compiler's output.
> One thing I thought was simply poor, unoptimized code with too many memory
> accesses. Like something that could be automatically generated (duh, that's
> what compilers do!). But then the same problem would exist in the Linux and
> MacOS executables. Do those engines not check those other formats at all?
> Or are there too few viruses for Linux and MacOS?
I highly doubt they do scan (much, if at all) other formats for other OSes. It's mostly a Windows problem.

Though "Reanalyze" shows ClamAV reporting "Osx.Malware.Agent-6370979-0". (Maybe I missed that before!)

>> Avast is still there with its suspicions.
>
> Found this: Report a false detection. Submitted the project URL.
> We'll see what happens.
I already reported the .ZIP to them, but maybe you think the URL would be more obvious?

Anyways, it now says "Avast : Clean" (on VirusTotal), but you're still getting 33/60 other false positives (most saying "generic", ugh).

Obviously you don't need my advice, but couldn't you split the Win32 .EXEs in half or something? Just make the end user recombine them. Heck, nop out the entire PE header, and add a plain text script to somehow recombine it. Heck, just .ZIP encrypt \binw\*.exe (like Japheth had to do with HX) with the password being (I don't know) "password". Put the password in the .ZIP comment (and/or readme), for full transparency.

Or not, I'm sure you don't need my ideas.
alexfru

USA,
27.11.2017, 03:10

@ Rugxulo
 

Smaller C compiler

Post reply

> > MacOS executables. Do those engines not check those other formats at
> all?
> > Or are there too few viruses for Linux and MacOS?
>
> I highly doubt they do scan (much, if at all) other formats for other OSes.
> It's mostly a Windows problem.
>
> Though "Reanalyze" shows ClamAV reporting "Osx.Malware.Agent-6370979-0".
> (Maybe I missed that before!)
I too did.

> >> Avast is still there with its suspicions.
> >
> > Found this: Report a false detection. Submitted the project URL.
> > We'll see what happens.
>
> I already reported the .ZIP to them, but maybe you think the URL would be
> more obvious?
Dunno. Just gave them the URL for the zip on github. They couldn't just scan by the project URL (can't traverse HTML?).

> Anyways, it now says "Avast : Clean" (on VirusTotal), but you're still
> getting 33/60 other false positives (most saying "generic", ugh).
>
> Obviously you don't need my advice, but couldn't you split the Win32 .EXEs
> in half or something? Just make the end user recombine them. Heck, nop out
> the entire PE header, and add a plain text script to somehow recombine it.
> Heck, just .ZIP encrypt binw*.exe (like Japheth had to do with HX) with the
> password being (I don't know) "password". Put the password in the .ZIP
> comment (and/or readme), for full transparency.
>
> Or not, I'm sure you don't need my ideas.
How about the two MZ chars stripped? Here's the link to download the project from the new experimental branch av. Follow the simple instructions in binw/combine.txt.
Rugxulo

Homepage

Usono,
28.11.2017, 13:49

@ alexfru
 

Smaller C compiler

Post reply

> How about the two MZ chars stripped? Here's [av.zip] the link to download
> the project from the new experimental branch av.
> Follow the simple instructions in binw/combine.txt.
Looks fine, no complaints.
alexfru

USA,
28.11.2017, 18:03

@ Rugxulo
 

Smaller C compiler

Post reply

> > How about the two MZ chars stripped? Here's [av.zip] the link to
> download
> > the project from the new experimental branch av.
> > Follow the simple instructions in binw/combine.txt.
>
> Looks fine, no complaints.
Cool! Merged into master (also moved combine.txt contents into readme.txt).
alexfru

USA,
23.11.2017, 20:31

@ Rugxulo
 

Smaller C compiler

Post reply

> > > Actually, MS Security Essentials deleted my local .ZIP
> > while I was just listing the files in it! So I had to go to
> > "Settings" and add it to "Excluded files and locations".
> >
> > Um... I had the project directory excluded on my Windows 7 because it
> was
> > slowing things down, but I just removed the exclusion and scanned the
> > directory with Security Essentials and all was OK. The virus/malware
> > definitions were last updated yesterday (version 1.257.257.0). What's on
> > your end?
>
> I'm on the wrong machine right now, but I did update the definitions
> yesterday. But I'm not imagining this, it definitely deleted it, ugh. Even
> after having similar problems like this, it's still annoying.
I just downloaded the .zip file from github and Security Essentials did indeed immediately find it bad, very bad (naturally, the most innocent file, smlrc.exe is sad to have Trojan:Win32/Tiggre!rfn). And it wouldn't let me get the file out of quarantine (bug?).
But there's no problem if the contents of the .zip file are sitting unpacked on the disk. Manually directing Security Essentials to scan my github directory yields nothing. Go figure.
alexfru

USA,
28.11.2017, 23:47

@ Rugxulo
 

Smaller C compiler

Post reply

> > Also, it's probably a good idea to include the project wiki pages
> > into the package since there's no /? or --help option in the binaries
> > and somehow those wiki pages are not really part of the project
> > (you don't get them in the .zip file downloaded from gitHub
>
> Sounds tedious, but I'll try (maybe).
I've moved the documentation as markdown files (.md) from the wiki to v0100/doc, so one can get it together with the rest of the project whether by git-cloning or downloading the archive file off github. Better than nothing, IMO.
Rugxulo

Homepage

Usono,
30.11.2017, 18:43
(edited by Rugxulo, 30.11.2017, 19:18)

@ alexfru
 

Smaller C compiler

Post reply

> I've moved the documentation as markdown files (.md) from the wiki to
> v0100/doc, so one can get it together with the rest of the project whether
> by git-cloning or downloading the archive file off github. Better than
> nothing, IMO.
Thanks! I'll definitely take a closer look.

<rant>

BTW, not to harp on it forever, but I wonder if these antiviruses ever test each other? Or if they test their own development tools? Surely that would be the first thing to do, to make sure they aren't compromised, right? :yes: What could go wrong? :lol3:

</rant>

EDIT:

> And it wouldn't let me get the file out of quarantine (bug?).
Okay, just for full transparency, if you're morbidly curious ....

Firefox 57.0.1 (64-bit), Win7 ... I go to the Github page and click "Clone or Download". It does download, but the file is 0 bytes. In the download window, it has a red circle with a white line in the center. "This file contains a virus or malware." Which is annoying, obviously, since VirusTotal gives zero false positives anymore! So that means Firefox is somehow aware of the .ZIP's "checkered" past (pardon the ridiculousness) but is too dumb to know that it has improved.

Right click -> Allow Download brings up a message box that can't be switched away from. I can't minimize Firefox, nor can I switch tabs even (although of course I can run other programs). Title is "Are you sure you want to allow this download?", actual message is "This file contains a virus or other malware that will harm your computer.", "You can search for an alternate download source or try again later." [Allow download] [Cancel]

(Alternate source?? Try again later??? Does that even make practical sense????)

So I click allow, and it then shows up correctly as 1.6 MB .ZIP. I can do "unzip -Cpaa *.zip *binw/readme.txt", and it will display the text correctly.

Right click -> Clear Downloads. Pointless, but I always do this. It just clears the history ... except here it also deletes the .ZIP. ("Remove from history" also does this!) So, sadly, I have to rename or move the file first before it does that ... else I have to jump through all the hoops again! (Maybe they assumed no one would ever rightfully unblock a file.)

Maybe it's just a silly Firefox bug (which I will not waste my time reporting). But I've previously had (rare) "errors" like this in Chrome, too, for other innocent stuff. I understand that viruses are a problem, but at some point it's insane to be so error-prone in false positives.

I don't blame you, obviously, just saying it's a giant mess, and I don't even do or use anything sensitive.

EDIT #2: Using the URL to master.zip at VirusTotal does give me 2/66 false positives (while uploading the file itself doesn't).
alexfru

USA,
03.12.2017, 03:47

@ Rugxulo
 

Smaller C compiler

Post reply

> <rant>
>
> BTW, not to harp on it forever, but I wonder if these antiviruses ever test
> each other? Or if they test their own development tools? Surely that would
> be the first thing to do, to make sure they aren't compromised, right?
> :yes: What could go wrong? :lol3:
>
> </rant>
:)

> EDIT:
>
> > And it wouldn't let me get the file out of quarantine (bug?).
>
> Okay, just for full transparency, if you're morbidly curious ....
>
> Firefox 57.0.1 (64-bit), Win7 ... I go to the Github page and click "Clone
> or Download".
Chrome and IE don't like the zip file either, although some time ago Chrome either didn't complain about it or let me have the file (you may still have it, although it's not immediately obvious how (the file is downloaded but with the wrong/temporary name; you now need to click on "show all" to see the option for keeping the file, which, I guess, not everyone is smart enough to try)). Speaking of mass hallucinations, they're losing it.

> Maybe it's just a silly Firefox bug (which I will not waste my time
> reporting). But I've previously had (rare) "errors" like this in Chrome,
> too, for other innocent stuff. I understand that viruses are a problem, but
> at some point it's insane to be so error-prone in false positives.
I don't recall which browser did it, but it did once tell me something like "this file isn't downloaded often and may be dangerous". Great logic. Fear all of the unusual.

> I don't blame you, obviously, just saying it's a giant mess, and I don't
> even do or use anything sensitive.
>
> EDIT #2: Using the URL to master.zip at VirusTotal does give me 2/66 false
> positives (while uploading the file itself doesn't).
Same shitty experience as with Security Essentials. It doesn't find any harm in the executables on the disk, but the zip file with all those same files downloaded from the internet is somehow bad for ya. Gotta ban zip files!
roytam

05.12.2017, 16:08
(edited by Rugxulo, 06.12.2017, 12:58)

@ Rugxulo
 

Smaller C compiler

Post reply

> EDIT #2: Using the URL to master.zip at VirusTotal does give me 2/66 false
> positives (while uploading the file itself doesn't).
1/66 now.
https://www.virustotal.com/#/url/c08ad8ccf56624f6d...710385a5e50ccaab91eac5a5e0988fb4ac573/detection
alexfru

USA,
12.12.2017, 08:26

@ Rugxulo
 

Smaller C compiler

Post reply

> > I've moved the documentation as markdown files (.md) from the wiki to
> > v0100/doc, so one can get it together with the rest of the project
> whether
> > by git-cloning or downloading the archive file off github. Better than
> > nothing, IMO.
>
> Thanks! I'll definitely take a closer look.
I also made most of the text in the .md files fit a 80-column screen.

I guess that would make things readier(?) for a package. What's the plan, if any? Looks like github's .zip is slightly bigger than the 1.44MB floppy. Take binl and binm out and all should fit. Not sure if anyone's actually gonna use a real floppy and maybe a real 386 PC. :)
Rugxulo

Homepage

Usono,
13.12.2017, 00:53

@ alexfru
 

Smaller C compiler

Post reply

> I also made most of the text in the .md files fit a 80-column screen.
>
> I guess that would make things readier(?) for a package. What's the plan,
> if any?
No huge plans. Sorry, I'm just slow and prone to procrastination. I do still wish to make a .ZIP, though.

> Looks like github's .zip is slightly bigger than the 1.44MB floppy.
> Take binl and binm out and all should fit.
I would omit all binaries (including binw/) except bind/ and bindp/. But of course leave everything else (so it can still Canadian cross-build or whatever).

> Not sure if anyone's actually gonna use a real floppy and maybe a real 386 PC. :)
You'd be surprised. Many 486 users came out of the woodshed for FreeDOS 1.2. And people still build retro PCs, too. Then again, floppies are rarely relied upon. Most such users still use bootable CDs.

But no, normally, FreeDOS isn't stuck to floppies only. FDNPKG is the network-aware package manager, and FDINST is the optional offline installer. So these .ZIPs are just slightly arranged in a special way to facilitate simple package management. Oh, there's also FDI and FDIMPLES (and auto-updated webpages like Development which I already linked you to).

So yeah, I anticipate that potential FreeDOS users will grab this via FDNPKG for their hard disks (and/or virtual machines).
Rugxulo

Homepage

Usono,
20.12.2017, 02:12

@ alexfru
 

Smaller C compiler

Post reply

(I just got this email. FYI, I quote it below.)

Subject: False positive file SmallerC.zip Request #05551922 ref:_00Db0Z3Sf._500b01K6GXz:ref
From: support@help2.avast.nospam

> Hello,
 >
> Thank you for reporting this false positive.
 >
> Our virus specialists have now cleared its reputation in our database.
 >
> With URLs this change should be instant, but it might take up to 24 hours with files.
 >
> For future reference you might also find the following article to be useful: Avast Clean Guidelines.
 >
>
> Best regards,
 >
> Avast Customer Care
Rugxulo

Homepage

Usono,
30.11.2017, 19:37

@ alexfru
 

Smaller C compiler

Post reply

> Include the project GitHub URL and the SHA of the top commit somewhere in
> the package description, so the package can be traced back if needed
Apparently the SHA of latest commit is included as main comment in .ZIP, so you can check via "unzip -z SmallerC-master.zip", which gives me this:

> Archive: SmallerC-master.zip
> 549e93389b9bbde8b87c4ad64fdfb757fbc7a880
Github says this (where "549e933" is a link):

> Latest commit 549e933 2 days ago
(click link)

> alexfru committed 2 days ago
> 1 parent 42644ea commit 549e93389b9bbde8b87c4ad64fdfb757fbc7a880
alexfru

USA,
03.12.2017, 03:48

@ Rugxulo
 

Smaller C compiler

Post reply

> Apparently the SHA of latest commit is included as main comment in .ZIP
Handy.
Rugxulo

Homepage

Usono,
18.06.2016, 18:20

@ alexfru
 

Smaller C compiler

Post reply

> > Sadly, some people have no imagination, certainly regarding DOS.
>
> My compiler targets Windows, Linux and RetroBSD as well, so, it's either
> the compiler or all four OSes. :)
You've done a very impressive job, so if your compiler isn't being significantly tested by outside developers, then I blame them, not you. That's what I meant. Developers can be narrow-minded, stuck in their ways ("all the world's a VAX").

Plus I think a lot of projects are too non-portable (or at least haven't well isolated the system-specific stuff). That probably doesn't help.

> > Isn't ancient GCC 2.7's CPP fairly small? I imagine that would be
> > (relatively) easy to port.
>
> I haven't seen it, but I have doubts.
It's fairly small, but it too is probably very POSIX heavy (or maybe relies on other weird stuff, alloca??). Dunno, maybe a bad suggestion, I too haven't looked closely.

> I didn't know about that. I have plan9.iso.bz2 downloaded in January 2015
> from Lucent.
http://akaros.cs.berkeley.edu/files/Plan9License says this:

"The University of California, Berkeley, has been authorised by
Alcatel-Lucent to release all Plan 9 software previously governed by
the Lucent Public License, Version 1.02 under the GNU General
Public License, Version 2."

So if you're worried about licensing, use that version. It can't be much worse than LCC's fork, can it?
alexfru

USA,
19.06.2016, 00:22

@ Rugxulo
 

Smaller C compiler

Post reply

> > > Sadly, some people have no imagination, certainly regarding DOS.
> >
> > My compiler targets Windows, Linux and RetroBSD as well, so, it's either
> > the compiler or all four OSes. :)
>
> You've done a very impressive job, so if your compiler isn't being
> significantly tested by outside developers, then I blame them, not you.
> That's what I meant. Developers can be narrow-minded, stuck in their ways
> ("all the world's a VAX").
Thanks. :)

> Plus I think a lot of projects are too non-portable (or at least haven't
> well isolated the system-specific stuff). That probably doesn't help.
The standard C is missing a few important things, which make it difficult to make a fully portable compiler. E.g. there's only system() for you to execute some other program. But the standard does not even require system() to return back to the caller and it doesn't tell how to interpret the returned value. And there's nothing in the standard about special symbols and various quotation and escaping mechanisms of the "command processor" (AKA shell). However, in DOS, Windows and Linux, system() normally returns and (with the exception of DOS's COMMAND.COM) it returns 0 on success and non-zero on failure. So, if you're conservative and cautious, you can use system() on selected platforms, perhaps only with minor platform specialization and trickery.

> > > Isn't ancient GCC 2.7's CPP fairly small? I imagine that would be
> > > (relatively) easy to port.
> >
> > I haven't seen it, but I have doubts.
>
> It's fairly small, but it too is probably very POSIX heavy (or maybe relies
> on other weird stuff, alloca??). Dunno, maybe a bad suggestion, I too
> haven't looked closely.
If I'm unhappy with Plan9's, I may take a look.

> > I didn't know about that. I have plan9.iso.bz2 downloaded in January
> 2015
> > from Lucent.
>
> http://akaros.cs.berkeley.edu/files/Plan9License says this:
>
> "The University of California, Berkeley, has been authorised by
> Alcatel-Lucent to release all Plan 9 software previously governed by
> the Lucent Public License, Version 1.02 under the GNU General
> Public License, Version 2."
>
> So if you're worried about licensing, use that version. It can't be much
> worse than LCC's fork, can it?
Not significantly.

Alex
alexfru

USA,
20.06.2016, 07:51

@ alexfru
 

Smaller C compiler

Post reply

> > > > Isn't ancient GCC 2.7's CPP fairly small? I imagine that would be
> > > > (relatively) easy to port.
> > >
> > > I haven't seen it, but I have doubts.
> >
> > It's fairly small, but it too is probably very POSIX heavy (or maybe
> relies
> > on other weird stuff, alloca??). Dunno, maybe a bad suggestion, I too
> > haven't looked closely.
>
> If I'm unhappy with Plan9's, I may take a look.
So, I've cleaned up and ANSI-C-fied the original Plan9's preprocessor and decided to compare it with the LCC version. It's funny, but there are bugs in both as can be seen when feeding them examples from the C standard. LCC aims at fixing some of them, but has a mixed success. It fixes a couple, fails to fix another and on some input just hangs. I might spend some cycles to investigate and fix some of these, but it's a bit of a bummer. I had higher expectations for this preprocessor.

There's another one (ucpp) and it seems to pass those tests and it's BSD-licensed, but it's larger and needs to be split into more .c files for compilation with Smaller C (alternatively, smlrc may be recompiled to accommodate for larger .c files).

We'll see...

Alex
RayeR

Homepage

CZ,
19.02.2014, 01:15

@ alexfru
 

Smaller C compiler

Post reply

Just a quick test, there's one waring with gcc 4.8.x:

smlrc.c: In function 'exprval':
smlrc.c:3906:33: warning: 'ofs' may be used uninitialized in this function [-Wma
ybe-uninitialized]
stack[i][1] = uint2int(stack[i][1] + 0u + ofs); // TBD!!! need extra
truncation?
^

---
DOS gives me freedom to unlimited HW access.
alexfru

USA,
19.02.2014, 05:33
(edited by alexfru, 19.02.2014, 06:23)

@ RayeR
 

Smaller C compiler

Post reply

> smlrc.c: In function 'exprval':
> smlrc.c:3906:33: warning: 'ofs' may be used uninitialized in this function
> stack[i][1] = uint2int(stack[i][1] + 0u + ofs);
That is a reasonable warning for a condition, whose impossibility the compiler fails to deduce (see, there's still a long road ahead of us in terms of i(nv|mplem)enting AI :-) ). ofs can be initialized to 0 explicitly (in its declaration) to suppress this warning.

There are a few other warnings needing cleanup. I should modify my build scripts to catch warnings early (I've changed them and lost the various -Wall's and -Wextra's in the process).

P.S. Thanks for noticing!
P.P.S. And thanks for trying out! :-)
roytam

30.03.2015, 04:49

@ alexfru
 

Smaller C compiler

Post reply

> Hello fellow DOS lovers!
>
> I'm not sure whether this fits best the Announce category or the Misc
> one, (moderator(s), feel free to correct).
>
> I've come across this thread,
> Old 8086
> version of pcc spotted (cross-compiles to DOS), and I'd like to
> share with you my recent work in the field.
>
> For the past year I've been working in my spare time on a C compiler that
> could potentially target DOS. And, in fact, it already can. :)
>
> You're most welcome to play with Smaller C, report bugs and discuss it (and
> contribute:).
>
> Alex
> P.S. Robert, indeed, I'm the author of the Frounze Commander. :) Thanks for
> my new account on the forum!
I read some discussions in IRC somewhere and there is a question raised: Why writing a custom parser when there is standard parser (bison/yacc) exists?
alexfru

USA,
30.03.2015, 06:42

@ roytam
 

Smaller C compiler

Post reply

> I read some discussions in IRC somewhere and there is a question raised:
> Why writing a custom parser when there is standard parser (bison/yacc)
> exists?
Multiple reasons:
- bison/yacc/etc don't help much and it's not all that hard to implement all this manually (I must've done a full lexer/parser at least once in my life myself!: ) One could also reasonably ask why writing yet another C compiler? Many already exist and are available. And who cares about it being able to target realmode DOS? :)
- I don't want too many dependencies on other tools
- If I'd used those other tools, I wouldn't have been able to make the compiler self-compilable for a long time (long = until it could compile those other tools), but I wanted it to compile itself and selfhost as early as possible

Alex
roytam

02.04.2015, 02:01

@ alexfru
 

Smaller C compiler

Post reply

> Multiple reasons:
> - bison/yacc/etc don't help much and it's not all that hard to implement
> all this manually (I must've done a full lexer/parser at least once in my
> life myself!: ) One could also reasonably ask why writing yet another C
> compiler? Many already exist and are available. And who cares about it
> being able to target realmode DOS? :)
> - I don't want too many dependencies on other tools
> - If I'd used those other tools, I wouldn't have been able to make the
> compiler self-compilable for a long time (long = until it could compile
> those other tools), but I wanted it to compile itself and selfhost as early
> as possible
>

hmm, what about win16 (NE output) support?
alexfru

USA,
02.04.2015, 10:08

@ roytam
 

Smaller C compiler

Post reply

> hmm, what about win16 (NE output) support?
I'm not familiar with NE (at all) or Win16 APIs (I had very little 16-bit programming experience with Windows). So, I don't know the exact problems that may need to be overcome other than just supporting a different kind of executable and rewriting pieces of the standard library. Windows 3.xx support was not and is not planned. Even Windows 9x/Me/2k isn't supported because the standard library links to a few functions that appear only in Windows XP (this can be worked around, though).

There's one potential problem in that Smaller C doesn't have good support for segmentation and far pointers. If Win16 is happy with an app having just 2 segments (code and combined data/stack) and there are no far pointers to things outside these 2 segments, then it might be doable. Otherwise some hacks are needed and they will cause performance degradation (e.g. the huge model support in DOS).

Why are you asking? Is this related to ReactOS? (they have linked to Smaller C recently).
Back to index page
Thread view  Board view
22378 Postings in 2074 Threads, 400 registered users, 81 users online (0 registered, 81 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum