OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 8:58 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 49 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject: Re: Smaller C (was: What does your OS look like?)
PostPosted: Tue Dec 23, 2014 8:03 am 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 923
Location: Finland
dosbox-0.74\src\dos\dos_execute.cpp wrote:
Code:
...
...
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.

alexfru wrote:
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.

_________________
Undefined behavior since 2012


Top
 Profile  
 
 Post subject: Re: Smaller C (was: What does your OS look like?)
PostPosted: Tue Dec 23, 2014 3:47 pm 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
Antti wrote:
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).


Top
 Profile  
 
 Post subject: Re: Smaller C (was: What does your OS look like?)
PostPosted: Sat Jan 10, 2015 12:36 pm 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
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.


Top
 Profile  
 
 Post subject: Re: Smaller C (was: What does your OS look like?)
PostPosted: Mon Apr 20, 2015 12:51 am 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
For those interested, it's now possible to pass and return structures by value (x86 only, though).


Top
 Profile  
 
 Post subject: Re: Smaller C (was: What does your OS look like?)
PostPosted: Sat Apr 25, 2015 10:08 pm 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
A few important bugfixes are uploaded.


Top
 Profile  
 
 Post subject: Re: Smaller C (was: What does your OS look like?)
PostPosted: Sat May 16, 2015 6:53 pm 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
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")


Top
 Profile  
 
 Post subject: Re: Smaller C (was: What does your OS look like?)
PostPosted: Sat Aug 15, 2015 3:08 am 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
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


Top
 Profile  
 
 Post subject: Re: Smaller C (was: What does your OS look like?)
PostPosted: Sun Sep 06, 2015 5:00 pm 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
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.


Top
 Profile  
 
 Post subject: Re: Smaller C (was: What does your OS look like?)
PostPosted: Thu Mar 23, 2017 6:39 pm 
Offline
Member
Member
User avatar

Joined: Sun Jul 14, 2013 6:01 pm
Posts: 442
alexfru, are 64 bit integers available in smallerc?

_________________
Operating system for SUBLEQ cpu architecture:
http://users.atw.hu/gerigeri/DawnOS/download.html


Top
 Profile  
 
 Post subject: Re: Smaller C (was: What does your OS look like?)
PostPosted: Thu Mar 23, 2017 7:33 pm 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
Geri wrote:
alexfru, are 64 bit integers available in smallerc?


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


Top
 Profile  
 
 Post subject: Re: Smaller C (was: What does your OS look like?)
PostPosted: Sat Apr 08, 2017 3:24 pm 
Offline
Member
Member
User avatar

Joined: Sun Jul 14, 2013 6:01 pm
Posts: 442
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?

_________________
Operating system for SUBLEQ cpu architecture:
http://users.atw.hu/gerigeri/DawnOS/download.html


Top
 Profile  
 
 Post subject: Re: Smaller C (was: What does your OS look like?)
PostPosted: Sat Apr 08, 2017 4:40 pm 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
Geri wrote:
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.

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

Unlikely.

Geri wrote:
or the compiler is not optimized?


From the department of documentation:
Quote:
Smaller C is not an optimizing compiler, but it does the job better than the typical small C implementation.


Geri wrote:
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?


Top
 Profile  
 
 Post subject: Re: Smaller C (was: What does your OS look like?)
PostPosted: Sat Apr 08, 2017 5:10 pm 
Offline
Member
Member
User avatar

Joined: Sun Jul 14, 2013 6:01 pm
Posts: 442
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.

_________________
Operating system for SUBLEQ cpu architecture:
http://users.atw.hu/gerigeri/DawnOS/download.html


Top
 Profile  
 
 Post subject: Re: Smaller C (was: What does your OS look like?)
PostPosted: Mon Apr 10, 2017 5:25 am 
Offline
Member
Member
User avatar

Joined: Thu Jul 12, 2012 7:29 am
Posts: 723
Location: Tallinn, Estonia
Geri wrote:
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.

_________________
Learn to read.


Top
 Profile  
 
 Post subject: Re: Smaller C (was: What does your OS look like?)
PostPosted: Tue Apr 11, 2017 9:26 am 
Offline
Member
Member
User avatar

Joined: Sun Jul 14, 2013 6:01 pm
Posts: 442
dozniak wrote:
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.

_________________
Operating system for SUBLEQ cpu architecture:
http://users.atw.hu/gerigeri/DawnOS/download.html


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 49 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: DotBot [Bot], SemrushBot [Bot] and 79 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group