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.
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.
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
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.
> 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.
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.
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:
> 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.
> > 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.
... > The binfmtc project allow one to treat C, C++, assembly code as shell > "scripts" by adding a comment:
> "Anti Vigilante" <antivigila...@pyrabang.com> wrote in message > news:1257294794.22260.32.camel@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:
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.
> > "Anti Vigilante" <antivigila...@pyrabang.com> wrote in message > >news:1257294794.22260.32.camel@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:
> 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.
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.
> > "Anti Vigilante" <antivigila...@pyrabang.com> wrote in message > > news:1257294794.22260.32.camel@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:
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.
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).
> 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.
> > 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.
> 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.
> 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:
> > 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
Binfmtc seems like a good way to at least experiment with the ideas.
I'm going to finish my own little language shortly and then start diving in.
I removed comp.lang.forth as I won't be needing it until I add it as an interface to the different layers.
John Passaniti <john.passan...@gmail.com> writes: > 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.
> 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.
On 4 nov, 01:33, Anti Vigilante <antivigila...@pyrabang.com> wrote:
> 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.
|
