Small and simple C compiler for x86 (DOS, Windows, Linux) and MIPS (RetroBSD).
I've adapted the D-Flat Windowing System for compilation with Smaller C.
Here's a screenshot of a demo application, MemoPad, using it.
Unreal mode is now supported in the compiler! This is a screen capture from DOSBox running tests/vesalfb.c compiled using the -dosu option. VirtualBox produces similar results (different color palette, no text message).
I've adapted ucpp 1.3.2 for use with Smaller C. No need for workarounds such as invoking gcc (e.g. with the -ppg option). smlrpp should now be invoked automatically and it should just work.
Just added an SDL clock demo for Windows.
I've merged the work-in-progress branch into master and now most of floating point support is available on x86 too (this includes functions from <math.h>).
The Mandelbrot set image you're seeing here has been generated by a new test/demo program, which uses floating point.
Late last year we made a series of improvements in RetroBSD and Smaller C (switched to compiling apps and libraries as MIPS16e, made numerous fixes and improvements in the emulator (including MIPS16e support) and shrank one large array in the compiler), which significantly reduced the compiler in size, like by 20+ KB. That extra space made me think of what else could be implemented or improved in Smaller C.
Of the largest language debts stood out floating point. I looked at it and decided to give it a try and it was perfect timing as the long Xmas/NY break was approaching. So, over the period of several weeks I've implemented and tested basic support for float. RetroBSD builds with double equivalent to float (32-bit single precision, software implementation as the PIC32MX CPU does not contain an FPU) and Smaller C follows suit.
This still is a work in progress and there are a few other limitations like several operators still unsupported with floats (++, --, +=, -=, *=, /=), but other than that things seem to be working quite well.
Evolution / source code visualization of Smaller C. I have no idea why someone would make one for my project.
What's new in the compiler?
- it can use FASM instead of NASM when compiling 32-bit protected
mode x86 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.
DPMI version of the compiler and DPMI support are in!