Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the board
Thread view  Mix view  Order  «  
 
Rugxulo(R)

Homepage

Usono,
07.05.2015, 10:33

@ alexfru

Smaller C compiler (tests under emulation)

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(R)

USA,
26.04.2015, 06:12

@ alexfru

Smaller C compiler

A few important bugfixes are uploaded.

alexfru(R)

USA,
20.04.2015, 08:52

@ alexfru

Smaller C compiler

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

alexfru(R)

USA,
02.04.2015, 10:08

@ roytam

Smaller C compiler

> 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).

roytam(R)

02.04.2015, 02:01

@ alexfru

Smaller C compiler

> 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(R)

USA,
30.03.2015, 06:42

@ roytam

Smaller C compiler

> 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(R)

30.03.2015, 04:49

@ alexfru

Smaller C compiler

> 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(R)

USA,
10.01.2015, 19:39

@ alexfru

Smaller C compiler

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(R)

USA,
21.12.2014, 11:28

@ alexfru

Smaller C compiler

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(R)

USA,
28.11.2014, 13:13

@ alexfru

Smaller C compiler

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

alexfru(R)

USA,
09.11.2014, 12:18

@ alexfru

Smaller C compiler

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(R)

USA,
14.09.2014, 12:03

@ alexfru

Smaller C compiler

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(R)

USA,
21.04.2014, 05:04

@ alexfru

Smaller C compiler

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(R)

USA,
10.03.2014, 09:45

@ alexfru

Smaller C compiler

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

alexfru(R)

USA,
02.03.2014, 06:29

@ alexfru

Smaller C compiler

New things:
- typedef
- __func__
- bugfixes

alexfru(R)

USA,
25.02.2014, 09:19

@ alexfru

Smaller C compiler

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(R)

USA,
19.02.2014, 21:04

@ Oso2k

Smaller C compiler

> 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;
}

Oso2k(R)

19.02.2014, 18:46

@ alexfru

Smaller C compiler

> 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(R)

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

@ RayeR

Smaller C compiler

> 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! :-)

RayeR(R)

Homepage

CZ,
19.02.2014, 01:15

@ alexfru

Smaller C compiler

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(R)

USA,
17.02.2014, 07:59

@ alexfru

Smaller C compiler

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.

Back to the board
Thread view  Mix view  Order  «  
 
15108 Postings in 1358 Threads, 246 registered users, 13 users online (0 registered, 13 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum