i will die if i can't use a HLL

[OSbud]

i can code in ASM alright. But i can't manage a big one such as OS coding. Please guide me how i can use a HLL such as C or C++ to code the OS. I have read in this forum that i have to use gcc, but how do i use functions such as printf() etc without having to write them...writing printf() is not complex, but writing the others is pretty tough.
[glow=red,2,300]Please help me... [/glow]:-\

[Tim]

Sorry, you've got to write printf etc. yourself. That's because it's your OS; printf from any other OS would rely on code in that OS, and it wouldn't be your OS then, would it?

Don't stress, read the tutorials, and take it one step at a time.

[OSbud]

When I code in GCC, without including any files do i straight away write:
int main()
{
...
}

and
i. not call any library functions
ii. can use int, long, ...data types
iii. can use struct
iv. can include files created this way
v. all of above

I wonder how one started when there was only ASM, and no C, C++

After creating a.out file, do i load it to floppy (my boot disk for my OS) in the required sector...

[Tim]

All of the above.

You can use anything built into the C language, as well as anything you write yourself. So immediately you can use all the normal keywords, but if you want to use a library function, you need to write it yourself.

However, you will need a custom loader for your C program. I suggest you download the GRUB sources from http://www.gnu.org/software/grub/ and look at the sample kernel in the doc directory, as well as the GRUB tutorial on http://www.osdever.net/. The GRUB sample kernel includes some setup code written in assembler as well as a short kernel, written in C, which you can modify. The GRUB tutorial will tell you how to put these onto a floppy disk that you can boot.

[OSbud]

Thankyou soooo much Tim, now i have some hope.

[proxy]

just to keep to hope alive for ya:

I have been successfully developing an OS in almost entirely C++ (some parts _need_ asm, but very little so far).

I have even re-written most of the libc for use in my OS, (strings.h and ctype.h were most important).

also vsprintf/printf was a big one, and it is suprisingly compleciated to get it to match the _exact_ functionality of the real thing, but i'm getting close minus the float/double support

so yes, HLL is definitely an option, C seems to be the be preference for msot people, but I've been really trying to do thing in an OOP sense.

For example, the IDT, and GDT in my OS are both singleton containers which overload the operator[] in order to access the entries (which also have functions to get/set the data in the entries).

proxy

[kataklinger]

And what about RTTI and EXCEPTIONS?

[proxy]

And what about RTTI and EXCEPTIONS?

well, simply disabled for now..

Code: Select all

-fno-rtti -fno-exceptions

those handle that pretty nicely, until i implement them, they are simply off limits...

but that doesn't mean i wont, just havent needed them yet.

proxy

[Solar]

Well, I aimed at doing a full-fledged C++ kernel, including RTTI and exceptions, if only for completeness' sake.

Shame is, you can find about as much info about kernel C++ runtime support requirements as on Pascal kernels or something alike... all they keep telling you is "just disable 'em".

As for the libc... don't throw stones at me for advertising my effort of creating a cross-platform, public domain libc so that finally everyone can have a libc to use in your OS without having to worry about licensing. For now, I'm on my own in this effort, but I would seriously welcome help, be it in hands-on coding help, or in "donating" code fragments for the stuff I don't have anything for yet.

http://pdclib.sourceforge.net

[proxy]

Posted by: Solar    Posted on: Today at 02:50:17am
Well, I aimed at doing a full-fledged C++ kernel, including RTTI and exceptions, if only for completeness' sake.

Shame is, you can find about as much info about kernel C++ runtime support requirements as on Pascal kernels or something alike... all they keep telling you is "just disable 'em".

As for the libc... don't throw stones at me for advertising my effort of creating a cross-platform, public domain libc so that finally everyone can have a libc to use in your OS without having to worry about licensing. For now, I'm on my own in this effort, but I would seriously welcome help, be it in hands-on coding help, or in "donating" code fragments for the stuff I don't have anything for yet.

http://pdclib.sourceforge.net

well if you promise to share any good RTTI and exception in kernel info you do find, i'll promise too also

as for your libc, seems like a really good idea, i've been trying to make mine as portable as possible while sticking to the standard. for example i've made a limits.h which for now only makes 1 arch based assumption (CHAR_BIT == the rest is derived from macros which compile down to constants

I'd love to contribute if i can, first i'm gonna check out your site to see what you already have. If it seems I have somthing to offer, i'll join up.

proxy

[proxy]

also, how do you plan to handle things which are inherant to the OS? (for example setjmp and console output).

proxy

[Tim]

setjmp/longjmp are inherent to the the compiler. Read the compiler's ABI specs. Write setjmp to save all callee-save registers. Write longjmp to restore these registers and do an indirect jump.

Console output (stdout or cout) is inherent to the OS. The C++ libraries I've seen have ifstream/ofstream based on FILE, which in turn they have based on read()/write(). So implement read() and write() and stdio and iostream are easy.

RTTI is compiler-dependent. I think gcc implements most of its RTTI in libgcc.a, so if you can get that to link, you've got RTTI. But IMHO RTTI is unnecessary as it defeats polymorphism (why use virtual functions at all when you can do a switch on the type of object?).

Exceptions are compiler- and OS-dependent. You need to either modify gcc to use your OS's exception handling, or make your OS's exception handling look like whatever your version of gcc expects.

[Solar]

When you check out the pdclib status, be aware that I have done some serious work on the string functions which I hadn't have the time to check in yet.

The concept is to:

1) Provide as much functionality in correct, generic, OS and compiler independent C code as possible, to hell with efficiency;

2) Provide the OS and compiler dependent stuff as "drop-in" patches for as many compiler / OS combinations as possible;

3) Provide "efficiency patches" (ASM and macros) which can be used as replacement for the generic code.

The basic idea is to avoid the "classic" #ifdef's as much as possible, and rely on drop-in file mods. (E.g., float.h, limits.h and stdint.h aren't in the generic code since they're platform dependent, and complex.h "decides" whether a compiler supports _Imaginary by including a header "__personality.h", which in turn defines a symbol __PERSONALITY_SUPPORTS_IMAGINARY or not.

This concept will be extended as we come across more OS / compiler dependent stuff (like, I haven't spend much thought on setjmp / longjmp yet).

All those files (float.h, limits.h, stdint.h, __personality.h) are kept in subdirectories named after the OS / compiler combination they're meant for.

That way, if a maintainer drops out of the project and support for platform X gets stale, that "staleness" is contained to the platform subdirectory, and doesn't touch the main code base.

A word on exception handling: the worst thing is, it's not only compiler / OS / CPU dependent, but also binary format dependent, which really doesn't help things...

[proxy]

Tim, thanks for the input, but i think you misread what i was getting at

Solar wants to create a stdlib which is minimally dependant on OS features/implementation and my point was that some function require OS specifics, how is solar to approach those?

However, Solar answered well

Solar, sounds very cool. Just to give you a status on my libc:

assert, string, ctype, iso646, limits, stdarg, stddef and (BSD style strings.h),

are complete minus locale support (all locale functions opperate as if in "C" locale, and therefore are just equivalents to other functions.

my organization is a .c and a .h file for each function, and tstd header simply includes the headers for every function it wishes to define.

much of stdio and stdlib are also done, but they mostely pay no attention to the notion of file handles and the like as i only have a stdout avail (main console).

i also did as much as i could in terms of defining functions in terms of others (for example strtok is pretty short when based on strpbrk and family).

there is _no_ asm present in my libs, though some og the IO functions do call OS specific functions.

perhaps one way to solve the os specific needs is to have the functions that the user is expected to define, then have the header have a macro (or inline function, depending on whether standard allows it to be a macro) which simply resolves to it.

for example:

Code: Select all

inline int fputc(int c, FILE *stream) {
  _os_do_fputc(c, stream);
}

that way all the person has to do to is create a function with C linkage called "_os_do_fputc" and link it with your lib. Hopefully, almost all output would be based on functions such as these basic ones, so to minimize the amount of neccessary implemented by user functions.

the way i see it right now things that are def OS specific are:

putting a char to a file (including stdout/stderr)
reading a char from stdin

malloc (calloc, realloc can be defined in terms of these)
free
signals
system (duh)

and just a few less obvious ones which aren't so bad

anyway, seems like a good idea either way

proxy

[Solar]

Solar, sounds very cool. Just to give you a status on my libc:

assert, string, ctype, iso646, limits, stdarg, stddef and (BSD style strings.h),

assert and iso646 are a piece of cake, and I got most of string done. stddef is also easy, and I already got a "C" locale-only version of ctype. (I'd like to take a look at a locale-aware version some day, since my solution for ctype doesn't scale well.) If you'd toss me your solution for stdarg under PD, I'd be a happy camper. (Refining is always better than rewriting.)

my organization is a .c and a .h file for each function, and tstd header simply includes the headers for every function it wishes to define.

Structure of pdclib (so far):

Code: Select all

/includes
    // first come typedef's and #defines used in more than one
    // header. Placed in individual headers as to avoid multiple
    // definition. Header guards are placed in the *including*
    // headers instead of these, so the preprocessor doesn't
    // have to touch 'em if they already have been included once.
    __NULL.h
    __WCHAR.h
    __size_t.h
    __tm.h
    __wchar.h
    __wint_t.h
    // Standard includes, one .h per include.
    assert.h
    complex.h
    ctype.h
    errno.h
    fenv.h
    ...
/functions
    /complex
        // in here, one .c file per function *group*
        cabs.c
        cacos.c
        ...
    /math
        // in here, one .c file per function *group*
        abs.c
        acos.c
        ...
    /stdio
        // in here, one .c file per *function*
        clearerr.c
        fclose.c
        ...
    /stdlib
        // in here, one .c file per *function*
        _Exit.c
        abort.c
        ...
    /string
        // in here, one .c file per *function*
        memchr.c
        memcmp.c
        ...
    // These are too small to warrant splitting up in individual .c files
    assert.c
    ctype.c
    errno.c
    fenv.c
    inttypes.c
    locale.c
    setjmp.c // probably to be moved to personality
    signal.c
    time.c
    wctype.c

As for "glue code", i.e. calling OS-specific functions, you're right, I forgot that. It's rather funny how little functionality ends up being OS-specific. printf() is a wrapper for fprintf() is a wrapper for vfprintf()... you end up with just a mere handful of functions being OS-specific, and I fully intend to document them clean and neat, so plugging pdclib into your environment, whether selfmade kernel or hosted, will be a charm. In the end, I need a CLib for my own OS, so I'll benefit from a clean interface myself.