OSDev.org

Its finally time to make my OS a self-compiling system.
I used tcc to make my os, and I was wondering what path others have chosen to go to make their own/steal a compiler. TCC is relativlely easy to port, as well as obviously having 100% compatibility with code generated ( I replaced the stdlib with my own OS's implementation [ Basic ] ).

I've seen others using FASM, but I'd prefer to focus on C generation.
As well, its wonderfully small size is perfect for a floppy-based os.

Any suggestions?

Speaking personally, I would love to get GCC working on my OS - I am more than a year away from that at the moment, though!

I would say that if you are familiar with a particular toolchain's internals, that is the way to go. If you are porting a C compiler, I guess you automatically get an assembler too - don't worry about FASM if that's not ultimately the way you want to go.

Well done for getting to the stage where you are thinking about being self-supporting though!

Cheers,
Adam

once you use newlib on your os, eventually you can port GCC

I'm getting around to porting the toolchain to my OS. I have a fully functional port of the Newlib at the moment, I'm just now trying to get my shell to talk to my console driver without crashing... Once that's done I'll be able to start thinking about running programs from a command line (with arguments), once that's done I can start thinking about porting binutils.

What shell do you use incidentally? Bash? or your own?

JamesM wrote:What shell do you use incidentally? Bash? or your own?

My own... I'm thinking of porting bash though.

OrOS wrote:It's finally time to make my OS a self-compiling system.
I used tcc ...
Any suggestions?

You're about a month or two ahead of me, I think. Which, unfortunately, means that I don't have any useful suggestions. I agree with your methods, so far -- I'm intending to steal & eventually rewrite tcc, probably the same with NASM, and definitely write my own linker (I'm using my own executable format). I'll probably do the assembler first .

Eventually I'll port GCC -- but it's a big bloated monster, I don't like its optimizations, and I prefer intel syntax for my asm.

I agree on every point, I have no interest at all in using gcc on my os, and since I want to keep it minimal ( floppy based ) theres no way I could fit it in any case ( However, I was thinking of a ramfs-based package system - load files on demand from an external device ( ie, hd0, fd0, et0 [ Which I haven't done yet...no ether stack at all ] )

(I'm using my own executable format).

Oh? Any specs/advantages over the common formats?

As I understand it, almost all executable formats accomplish the same thing, but ...

Since it's mine, I don't have to put in any legacy BS like the PE/COFF format has,

The main parts of the executable header are human readable, unlike ELF

A fully functional header (with no symbol table) adds as little as 40 bytes to the executable over the raw machine language

Until I write my linker, it takes about 30 seconds to type a complete header (as a separate segment) onto the front of an assembler file by hand (since it's human readable)

The way I've started it, it should be completely extensible, using tagged sections, later -- so I can add whatever the hell I need to, when I can figure out what it is that I need

And the main advantage, that I don't think the other formats can manage at all, is the concept of a fixed error-recovery entrypoint, that is known by the scheduler and error handling manager. If a program gets an exception of any sort, instead of just killing the program (maybe with a core dump or unreadable debug screen) -- the system can call the app's own error recovery code, and that code can take one last shot at trying to save your work and/or saving USEFUL debug info, before the app dies.

I take it you're not familiar with signal()?

A) With traditional signal(), not all signals can be caught -- and the ones that can are mostly software generated -- my deal is to give apps an opportunity to catch all HARDWARE generated exceptions

B) For each signal() that can be caught, you have to catch each one separately (annoying)

C) A GPF (for example) will crash your app with no possiblilty of catching with a signal() error routine, but my explicit error handler will ALWAYS give an app a chance to do what it can.

bewing wrote:C) A GPF (for example) will crash your app with no possiblilty of catching with a signal() error routine, but my explicit error handler will ALWAYS give an app a chance to do what it can.

A GPF signals SIGSEGV. At least, it does on my machine.

Yep, a GPF causes SIGSEGV in posix.

bewing wrote:A) With traditional signal(), not all signals can be caught...

Only SIGSTOP and SIGTERM, to my knowledge.

...my deal is to give apps an opportunity to catch all HARDWARE generated exceptions

I think it is a bad idea to have hardware exceptions caught by userspace. One, it opens the door for all kinds of security breaches, and two, handling hardware exceptions is what the kernel's interrupt handlers are for, really.

You could enable a userspace application to register a callback hook which gets called once the kernel handled the hardware exception.

B) For each signal() that can be caught, you have to catch each one separately (annoying)

You're free to add a function not in the C or POSIX standards that allows a "generic" signal handler to be registered.

C) A GPF (for example) will crash your app with no possiblilty of catching with a signal() error routine, but my explicit error handler will ALWAYS give an app a chance to do what it can.

As already said, a SIGSEGV can be caught. But generally, there is very little you can do in your application, because it usually points to your programming being screwed up in the first place...

Solar:

Wikipedia wrote:SIGTERM is the default signal sent to a process by the kill or killall commands. It causes the termination of a process, but unlike the SIGKILL signal, it can be caught and interpreted (or ignored) by the process.

I believe SIGKILL is the uncatchable one.