Re: Source based OS
Rod Pemberton
news:1257294794.2...@4k.amiga.home...
> [snip of OS development ideas]
> ...
> I'm also looking for the color Forth source code to model my work after.
>
Have you asked in comp.lang.forth? (added)
Rod Pemberton
Rod Pemberton
> Such is already possible in color Forth, but I get headaches when doing
> postfix somersaults.
FORTH is about the closest thing to a source based OS. Most of the FORTH
system (OS and language) is in FORTH. The reason is that most FORTH "words"
(subroutines or procedures) are written in FORTH. There is only a small
subset of "words" (sometimes called "primitives") that are coded in assembly
(or C). It's not likely that going to find that as a feature of other OSes.
> ... but I get headaches when doing postfix somersaults.
Well, these might help:
http://forpost.sourceforge.net/forthwiz.html
http://www.cs.bgu.ac.il/~vassilii/forth-opt/
The second one *had* a working online Javascript page, but I can't seem to
locate it... It has source as forth-opt.zip. It was more complete.
The first one's source will have to be "grabbed" from the webpage. It's
easy to modify.
> The idea is that after boot all software is either in source form in
> folders on the filesystem or in binary form in a cache area which is
> transparently accessed from disk or ram.
The binfmtc project allow one to treat C, C++, assembly code as shell
"scripts" by adding a comment:
Binfmtc
http://www.netfort.gr.jp/~dancer/software/binfmtc.html
> What it needs is three layers:
> Editable area
> - This is where source is loaded and manipulated
> Workspace area
> - The operating stack of editors, interpreters, and compilers as well as
> scratch space is allocated here
> Executable area
> - This is where binaries ready for use are located
It's your OS... (up to you).
> There are libraries of code but not in the traditional sense since
> everything is compiled or reused as needed.
...
> I'm also looking for the color Forth source code to model my work after.
My reply post made it to comp.lang.forth. I'm not sure why nobody replied.
HTH,
Rod Pemberton
John Passaniti
> news:1257294794.2...@4k.amiga.home...
> > I'm interested in the development of a source based Operating System.
> > Such is already possible in color Forth, but I get headaches when doing
> > postfix somersaults.
One such operating system is... Linux. It's from four years ago:
http://bellard.org/tcc/tccboot.html
It's more a proof-of-concept toy than something useful, but I found it
amusing. They started with a C compiler that fits in 100k of object
code and generates native code. Then, they took a full Linux kernel
(2.4.26) with minor modifications to the code. Finally, they added a
bit of code to aggregate all of the source files. On my machine
running under VirtualBox, it compiles Linux from sources in about six
seconds.
And again, I'm not suggesting this is anything more than a toy. But
it serves several useful purposes:
1. It's a beautiful hack.
2. It demonstrates a C compiler that is smaller than some Forth
implementations.
3. It's wicked-fast, considering what it has to do.
4. It shows that one could build an operating system that is
dynamically compiled from sources.
5. It serves as a reminder to the Forth community that we're not
living in 1980 anymore.
Incidentally, elsewhere the C compiler (tcc) is being used in an
interesting way-- using C as a scripting language. Building the
compiler into an application, one can extend that application in C,
issue code interactively and test it, and other tricks like using the
compiler as a library for dynamic code generation from within an
application.
So yes, the idea of an fully general-purpose operating system
dynamically built from sources can be done-- and has been done. And
while tccboot was really just a non-trivial demo of the tcc C
compiler, one can easily imagine a more serious attempt.
Alexei A. Frounze
Oh, how I want that. And not just from the application, but from the
application under the debugger, including applications w/o source
code, just symbols or none at all. :)
> So yes, the idea of an fully general-purpose operating system
> dynamically built from sources can be done-- and has been done. And
> while tccboot was really just a non-trivial demo of the tcc C
> compiler, one can easily imagine a more serious attempt.
Alex
Rod Pemberton
news:970abf57-7f0b-4536...@o10g2000yqa.googlegroups.com...
> > "Anti Vigilante" <antivigila...@pyrabang.com> wrote in message
> > news:1257294794.2...@4k.amiga.home...
> > > I'm interested in the development of a source based Operating System.
> > > Such is already possible in color Forth, but I get headaches when
doing
> > > postfix somersaults.
>
> One such operating system is... Linux. It's from four years ago:
>
> http://bellard.org/tcc/tccboot.html
>
Good call!
I was aware of tcc and tccboot. But, I was interested in the C
compiler/compilation techniques and was uninterested in Linux being compiled
from sources.
> It's more a proof-of-concept toy than something useful, but I found it
> amusing. They started with a C compiler that fits in 100k of object
> code and generates native code. Then, they took a full Linux kernel
> (2.4.26) with minor modifications to the code. Finally, they added a
> bit of code to aggregate all of the source files. On my machine
> running under VirtualBox, it compiles Linux from sources in about six
> seconds.
>
Is there more info on what "minor modification" and "added a bit of code"
means? And, did they do too much for anyone to recreate on a 2.6.x kernel?
A while back, I casually looked at porting tcc to DOS (via DJGPP). It
seemed to be dependent on a number of advanced Linux C library calls.
> And again, I'm not suggesting this is anything more than a toy. But
> it serves several useful purposes:
>
> 1. It's a beautiful hack.
> 2. It demonstrates a C compiler that is smaller than some Forth
> implementations.
> 3. It's wicked-fast, considering what it has to do.
> 4. It shows that one could build an operating system that is
> dynamically compiled from sources.
> 5. It serves as a reminder to the Forth community that we're not
> living in 1980 anymore.
>
Nice summary.
> And while tccboot was really just a non-trivial demo of the tcc C
> compiler, one can easily imagine a more serious attempt.
For a non-Linux, simple OS, coded in C, I suspect one wouldn't need a C
compiler even as powerful as tcc/tccboot. Tcc/tccboot could probably be
reduced substantially in terms of functionality and be sufficient to boot an
OS. IMO, Ron Cain's ancient and very limited Small-C C compiler can compile
what's needed for an OS in C. It only compiles a subset of C and is missing
some niceties like struct's, logical operators, floats, etc. The x86
versions produce unbelievably horrid code, but the binaries execute. Even
though it only uses two registers and the stack, the code doesn't execute as
slowly as one would expect.
Rod Pemberton
peekay
maybe following Ray's present attempts to explain
in text and movie formats will be able to give the
needed insight into colorForth source codes
another member (jmdrake) has also uploaded a
remarkable writeup
www.groups.google.com/group/Color-Forth
(look in *pages* and also *files* sections)
John Passaniti
> Is there more info on what "minor modification" and "added a bit of code"
> means? And, did they do too much for anyone to recreate on a 2.6.x kernel?
The README that comes with tccboot describes the changes and the
archive has the 15k diff file to apply to the Linux sources. I don't
see why this technique couldn't be applied to any version of Linux,
*BSD Unix, or any other operating system written in C. But it would
be silly to do so. tcc is not an optimizing compiler, so the code it
generates is far from optimal. But that again isn't the point. The
author wanted to show that tcc was complete enough to compile
something non-trivial (like Linux).
> A while back, I casually looked at porting tcc to DOS (via DJGPP). It
> seemed to be dependent on a number of advanced Linux C library calls.
I haven't looked at the code for tcc recently, but can't imagine that
to be the case. The core of tcc are routines that don't require any
library support at all. Now, the version of tcc that you build into
applications probably has dependencies on libraries to read object
file symbol tables and other operating system specific stuff. But you
would expect that given what it does.
Regardless, I brought up tccboot here because it shows what is
possible, not that one would actually want to do it with tcc and
Linux.
Aleksej Saushev
> On Nov 5, 5:18О©╫am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
>> Is there more info on what "minor modification" and "added a bit of code"
>> means? О©╫And, did they do too much for anyone to recreate on a 2.6.x kernel?
>
> The README that comes with tccboot describes the changes and the
> archive has the 15k diff file to apply to the Linux sources. I don't
> see why this technique couldn't be applied to any version of Linux,
> *BSD Unix, or any other operating system written in C. But it would
> be silly to do so. tcc is not an optimizing compiler, so the code it
> generates is far from optimal. But that again isn't the point. The
> author wanted to show that tcc was complete enough to compile
> something non-trivial (like Linux).
NetBSD kernel may be built with pcc, which is another small C compiler,
AFAIR changes were pretty minimal.
--
HE CE3OH...
Rod Pemberton
>
> The core of tcc are routines that don't require any
> library support at all.
Ok.
> Now, the version of tcc that you build into
> applications probably has dependencies on libraries to read object
> file symbol tables and other operating system specific stuff.
Ah, yes, that's what I ran into. Thanks.
> Regardless, I brought up tccboot here because it shows what is
> possible, not that one would actually want to do it with tcc and
> Linux.
Yes, but as a.o.d. is on the other side of this conversation (with at least
me on both... ). :-)
It's an interesting idea to use a compiler (or interpreter) for OS startup,
instead of precompiled binaries to start an OS. Not only is the compiler
(or interpreter) being used to bootstrap the OS, but it's doing so in
realtime. Except for FORTH, I'm not sure that's something we would've seen
done years ago, especially with compilation.
While it's not optimal in terms of speed, using a compiler or interpreter to
execute an OS can reduce complexity and allow rapid development of an OS.
Rapid development is important to OS development. Typically, you've got one
man to do untold numbers man hours of work. The OS could be compiled to
optimized binaries after the development work is done.
Rapid development is one of the reasons I chose C over assembly for my OS,
and why I chose DOS over Linux or Windows as the host OS. Many intricacies
of coding in assembly are solved by the C compiler and DOS imposes few
limitations on execution of non-DOS code.
With my own in progress OS, I plan to wean it off of it's current C
compilers (and C library usage...) and rewrite it to use very minimal or a
subset of C or a language similar to a small subset of C. I've already done
this for many personal applications. So, examples of using tcc or Small-C
or pcc, or a de-obfuscated IOCCC C compiler entry is of interest.
Rod Pemberton