Smaller C (was: What does your OS look like?)

[Antti]

Code: Select all

...
...
 31     const char * RunningProgram="DOSBOX";
 32
 33     #ifdef _MSC_VER
 34     #pragma pack(1)
 35     #endif
 36     struct EXE_Header {
 37             Bit16u signature;       /* EXE Signature MZ or ZM */
 38             Bit16u extrabytes;      /* Bytes on the last page */
 39             Bit16u pages;           /* Pages in file */
 40             Bit16u relocations;     /* Relocations in file */
 41             Bit16u headersize;      /* Paragraphs in header */
 42             Bit16u minmemory;       /* Minimum amount of memory */
 43             Bit16u maxmemory;       /* Maximum amount of memory */
 44             Bit16u initSS;
 45             Bit16u initSP;
 46             Bit16u checksum;
 47             Bit16u initIP;
 48             Bit16u initCS;
 49             Bit16u reloctable;
 50             Bit16u overlay;
 51     } GCC_ATTRIBUTE(packed);
...
...
...
361     if (!iscom) {
362             /* Check if requested to load program into upper part of allocated memory */
363             if ((head.minmemory == 0) && (head.maxmemory == 0))
364                     loadseg = (Bit16u)(((pspseg+memsize)*0x10-imagesize)/0x10);
365     }
...
...

Above is the the source code from DOSBox. All my real world experiments (e.g. on DR-DOS) support this. By using "min RAM = 0" and "max RAM = 0" combination, you are requesting that the program is loaded into upper part of allocated memory.

the reported problem is nowhere to be found and the suggestion is invalid.

The suggestion of not using "max RAM = 0" is valid. But this discussion has reached its end.

[alexfru]

The suggestion of not using "max RAM = 0" is valid. But this discussion has reached its end.

You started the discussion by telling me that there probably was a problem in Smaller C because of 0 in this field of the executable's exe header. We just found out that this 0 in smlrc.exe causes no problem neither to smlrc.exe itself nor to any other program. The suggestion of using 0xFFFF or some other non-zero value instead of this 0, while it may be applicable somewhere else, is therefore not applicable to Smaller C and is thus invalid. Invalid in the context of this discussion. I hope you were not suggesting that I change this 0 in all DOS programs in existence, not just smlrc.exe, right? Yes, the discussion has reached its logical end and if it hadn't happened, probably nobody would've gained or lost anything. Except, perhaps an extra bit of knowledge about the stuff (I mean that code from DOSBox and how Smaller C executables work in practice).

[alexfru]

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.

[alexfru]

For those interested, it's now possible to pass and return structures by value (x86 only, though).

[alexfru]

A few important bugfixes are uploaded.

[alexfru]

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]

I just added DPMI support and uploaded DOS DPMI binaries of the compiler.
As part of this effort I implemented support for the a.out executable file format (OMAGIC) with relocation records in the linker.
a.out is simpler and easier to load than ELF, so I hope this may be useful to someone.
https://github.com/alexfru/SmallerC

[alexfru]

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.

[Geri]

alexfru, are 64 bit integers available in smallerc?

[alexfru]

alexfru, are 64 bit integers available in smallerc?

No, you have to emulate them as pairs of 32-bit integers.

[Geri]

i did some calculations with smallerc (unreal mode, booted on bare metal).

i am not satisfyed with the speed.
i would be happy to see hints to reach bigger performance.

for example filling up ~1 gbyte of ram with 0-s (from 16 mbyte to 1g) takes approx 10 seconds on intel atom n45x (approx 100 mbyte/sec).

while doing the same thing (the same algorythm on 32 bit, for cycle with writing the 32 bit wide integer array) with gcc (-O3 -s) is around 0,2-0,4 sec (effectively ~4 gbyte / sec).

what is the reason of this large difference? the unreal mode and the cpu itself? or the compiler is not optimized? or there is an optimization flag i should pass to the compiler to have optimised code compiled?

[alexfru]

i did some calculations with smallerc (unreal mode, booted on bare metal).

i am not satisfyed with the speed.
i would be happy to see hints to reach bigger performance.

for example filling up ~1 gbyte of ram with 0-s (from 16 mbyte to 1g) takes approx 10 seconds on intel atom n45x (approx 100 mbyte/sec).

while doing the same thing (the same algorythm on 32 bit, for cycle with writing the 32 bit wide integer array) with gcc (-O3 -s) is around 0,2-0,4 sec (effectively ~4 gbyte / sec).

Right.

what is the reason of this large difference? the unreal mode and the cpu itself?

Unlikely.

or the compiler is not optimized?

From the department of documentation:

Smaller C is not an optimizing compiler, but it does the job better than the typical small C implementation.

or there is an optimization flag i should pass to the compiler to have optimised code compiled?

No flag will magically introduce optimization.

However, if you want a faster memset(), you can implement it in assembly.

But didn't you want to just emulate a bunch of subleq instructions instead?

[Geri]

yes, i only need to emulate the subleq instruction set, paint the screen, and manage io.
however, the subleq emulator algo also runs terrible, only half million instruction per second or less (code compiled with gcc does 200-400 million per second)

but i did additional tests. with inline assembly in smallerc unreal mode, i get beethwen 1-1.5 gbyte/sec memory write and overally really nice performance. so i just will rewrite the subleq instruction emulation to inline assembly, and that magically will fix the most important performance problems. not all problems, becouse the rest of the code will stay in c, that will add 10-20 seconds to the boot process.

[dozniak]

so i just will rewrite the subleq instruction emulation to inline assembly, and that magically will fix the most important performance problems. not all problems, becouse the rest of the code will stay in c, that will add 10-20 seconds to the boot process.

I guess using a sane optimising C compiler is not an option here, right? That would be too portable and too fast.

[Geri]

I guess using a sane optimising C compiler is not an option here, right? That would be too portable and too fast.

[/quote]

i am satisfyed with smallerc for x86 kerneldev at the moment, i guess this is the best and most simply solution to build a kernel if you dont want to deal with protected mode, or obsolote development technologies.