'hello world' OS

[Santanu Chatterjee]

Hello all,

I would like to know how an OS makes a computer boot up.
For that, as a start I would like to see an e_ample (read the
underscore as the letter before y, as the keyboard here is
defective) C program (along with instructions on how to compile
and usae it) that will take over when the computer boots and
print "hello world" and reboots the machine when 'enter' is
pressed. This will be something of a "hello world" OS (for me)
(I have tried to go through the boot.S (not sure about the name)
program in the Linu_ kernel source, but I could not understand
it since I am not familiar with assembly language).

I would be glad if someone could please point me in the right
direction.

Regards,
Santanu

 

[Case]

Hello all,

I would like to know how an OS makes a computer boot up.
For that, as a start I would like to see an e_ample (read the
underscore as the letter before y, as the keyboard here is
defective) C program (along with instructions on how to compile
and usae it) that will take over when the computer boots and
print "hello world" and reboots the machine when 'enter' is
pressed. This will be something of a "hello world" OS (for me)
(I have tried to go through the boot.S (not sure about the name)
program in the Linu_ kernel source, but I could not understand
it since I am not familiar with assembly language).

I would be glad if someone could please point me in the right
direction.

Here's a program that waits for an 'x'. Using any other input
for a program like this is dangerous and not standard C.

#include <stdio.h>

int main(void)
{
printf("hello world\n");
while (getchar() != 'y' - 1)
{
}
}

HTH

Case

 

[Richard Bos]

I would like to know how an OS makes a computer boot up.

It doesn't. The ROM bootstrap loader does. _How_ it does this is
completely system-dependent, and therefore you should ask about it in a
newsgroup dedicated to the architecture you are interested in. There is
no C program which can demonstrate this for more than a single
architecture, and for most you will need low-level system calls, since
the higher level functions used by ISO C are dependent on the very OS
you want to replace.

Richard

 

[Richard Bos]

Here's a program that waits for an 'x'. Using any other input
for a program like this is dangerous and not standard C.
#include <stdio.h>

int main(void)
{
printf("hello world\n");
while (getchar() != 'y' - 1)
{
}
}

Beautiful. Not only has it nothing whatsoever to do with the question,
it is even wrong. (Hint: what makes you think the ISO C Standard
mandates ASCII?)

Richard

 

[Joona I Palaste]

Beautiful. Not only has it nothing whatsoever to do with the question,
it is even wrong. (Hint: what makes you think the ISO C Standard
mandates ASCII?)

I figure there is no portable way whatsoever to guarantee an integer
value corresponds to the character 'x' without actually using the
character constant
'x'
either by itself, or as part of an array or string, at some point in
the C source code.
For characters corresponding to digits from 0 to 9 it can be done, but
I don't think it can be done for any other characters.

 

[Dan Pop]

I would like to know how an OS makes a computer boot up.

This is beyond the capabilities of any OS. At least the first stages
of the booting procedure are handled by programs that are not OS-specific.
These programs, are, however, heavily platform specific.

For that, as a start I would like to see an e_ample (read the
underscore as the letter before y, as the keyboard here is
defective) C program (along with instructions on how to compile
and usae it) that will take over when the computer boots and
print "hello world" and reboots the machine when 'enter' is
pressed.

There is no way to write such a program in portable C. Because there is
no OS, such a program would have to be written as a freestanding
application, i.e. all its output must be generated by its own means,
with no standard library support. And, with no standard library
support, there is no portable way of generating any output.

Furthermore, such a program may have to do things that cannot be done in
C at all, like setting various CPU registers to appropriate values.

This will be something of a "hello world" OS (for me)
(I have tried to go through the boot.S (not sure about the name)
program in the Linu_ kernel source, but I could not understand
it since I am not familiar with assembly language).

I would be glad if someone could please point me in the right
direction.

The right direction is to start learning assembly programming. It cannot
be bypassed when programming at this level, even if it's merely asm
statements embedded in C code.

And once you learn assembly, you'll discover that you have no need for C
at all for implementing the program you have in mind.

Dan

 

[Jeremy Yallop]

I figure there is no portable way whatsoever to guarantee an integer
value corresponds to the character 'x' without actually using the
character constant
'x'
either by itself, or as part of an array or string, at some point in
the C source code.

#include <string.h>
#include <ctype.h>

int is_x(int c) /* C locale */
{
return islower((unsigned char)c)
&& strchr("abcdefghijklmnopqrstuvwyz", c) == NULL;
}

Jeremy.

 

[Thomas Matthews]

Hello all,

I would like to know how an OS makes a computer boot up.

A better place to discuss your issue is in Another place is

For that, as a start I would like to see an e_ample (read the
underscore as the letter before y, as the keyboard here is
defective) C program (along with instructions on how to compile
and usae it) that will take over when the computer boots and
print "hello world" and reboots the machine when 'enter' is
pressed. This will be something of a "hello world" OS (for me)
(I have tried to go through the boot.S (not sure about the name)
program in the Linu_ kernel source, but I could not understand
it since I am not familiar with assembly language).

The boot sequence is platform dependent and usually differs
by platform and operating system.

A common sequence is:
1. Turn off all interrupts
2. Perform diagnostics (i.e. memory testing, device testing)
3. Initialize interrupt and other vectors.
4. Initialize memory structure (including stacks).
5. Initialize 'C' run-time library.
6. Jump to "main" function in C program.

Platforms with more complex operating systems would have different
sequences (and more complicated ones). Much of the boot code is
written in assembly language. The run-time environment for the
high level language must be initialized before a high-level
language can be executed.

I would be glad if someone could please point me in the right
direction.

Regards,
Santanu

On many platforms, your executable program is loaded into memory
and executed by the operating system. Your program has no idea
how long the platform has been operational before your program
is executed.


--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[Case]

Beautiful. Not only has it nothing whatsoever to do with the question,
it is even wrong. (Hint: what makes you think the ISO C Standard
mandates ASCII?)

The OP is unable to type an 'x' that's why I used his
suggestion to get there. Thanks for pointing out that
it has nothing to do with the question, I did not know
that. And, on his OS, Linu_, ASCII is quit common, if
I'm right; but could you please confirm. BTW, do you
know a real world character set in which 'x' != 'y' - 1?

Case

 

[Joona I Palaste]

#include <string.h>
#include <ctype.h>

int is_x(int c) /* C locale */
{
return islower((unsigned char)c)
&& strchr("abcdefghijklmnopqrstuvwyz", c) == NULL;
}

Quite clever. AFAIK, however, this can be only done for one character in
one C program. If we were trying to use such functions to identify *two*
characters, the best we could achieve would be knowing whether the input
is *either* of them, but we couldn't know *which*. If we used those
alphabet strings missing one letter, both letters would show up in each
other's alphabet strings. But if we used only one, missing two letters,
there would be no way to tell which one of them the input was.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I said 'play as you've never played before', not 'play as IF you've never
played before'!"
- Andy Capp

 

[Richard Bos]

The OP is unable to type an 'x' that's why I used his
suggestion to get there.

Then first of all, you should learn to snip, because you made it look as
though you replied to that whole post; and second, how would a program
that _waits_ for an 'x' help someone who cannot _type_ an 'x'?

And, on his OS, Linu_, ASCII is quit common, if I'm right;

So bloody what? This is comp.lang.c, not comp.lang.c.linux.

BTW, do you know a real world character set in which 'x' != 'y' - 1?

No, but I do know one in which not all letters are consecutive.

Richard

 

[Dan Pop]

Here's a program that waits for an 'x'. Using any other input
for a program like this is dangerous and not standard C.

#include <stdio.h>

int main(void)
{
printf("hello world\n");
while (getchar() != 'y' - 1)
{
}
}

Now explain how is it supposed to work on a freestanding platform, where:

1. The name and interface of the startup function is
implementation-defined.

2. Neither printf nor getchar are available (they typically rely on the
existence of an OS, but there is none in our case).

3. #include <stdio.h> may stop the compilation process with a message like

test.c:1:20: stdio.h: No such file or directory

Dan

 

[Dan Pop]

Beautiful. Not only has it nothing whatsoever to do with the question,
it is even wrong. (Hint: what makes you think the ISO C Standard
mandates ASCII?)

It doesn't have to. EBCDIC satisfies the poster's assumption, as well.
Good luck finding a conforming hosted implementation whose execution
character set is not based on (i.e. an extension of) either ASCII
or EBCDIC.

Dan

 

[Dan Pop]

I figure there is no portable way whatsoever to guarantee an integer
value corresponds to the character 'x' without actually using the
character constant
'x'
either by itself, or as part of an array or string, at some point in
the C source code.

I was about to say that '\U0078' would do in C99, but it appears to be
a constraint violation: you can't use UCNs for the members of the basic
source character set. Only the ASCII characters that aren't part of the
basic source character set can be represented with UCNs: $, @ and `.

Dan

 

[Joona I Palaste]

I was about to say that '\U0078' would do in C99, but it appears to be
a constraint violation: you can't use UCNs for the members of the basic
source character set. Only the ASCII characters that aren't part of the
basic source character set can be represented with UCNs: $, @ and `.

Now this question is perhaps off-topic for comp.lang.c, but I don't
understand *why* you can't use UCNs for members of the basic character
set. What is the rationale behind this constraint?

 

[Jeremy Yallop]

Quite clever. AFAIK, however, this can be only done for one character in
one C program. If we were trying to use such functions to identify *two*
characters, the best we could achieve would be knowing whether the input
is *either* of them, but we couldn't know *which*.

Okay, here's another way, which doesn't have that restriction:

if (c == tolower('X'))

Jeremy.

 

[Case -]

Huh, what can he mean here? And, the OP is not even able to type
an 'x'. The question is, at least a bit, off-topic too. Sorry
guys, and especially a sorry to the OP; I'll try not to do it again.

Now explain how is it supposed to work on a freestanding platform, where:

1. The name and interface of the startup function is
implementation-defined.

2. Neither printf nor getchar are available (they typically rely on the
existence of an OS, but there is none in our case).

3. #include <stdio.h> may stop the compilation process with a message like

test.c:1:20: stdio.h: No such file or directory

This point 3. has a causality problem. If you're able to
run a C compiler, a C compiler that is able to print, then
I guess stdio.h will be close enough.

Case

 

[Kenneth Brody]

#include <string.h>
#include <ctype.h>

int is_x(int c) /* C locale */
{
return islower((unsigned char)c)
&& strchr("abcdefghijklmnopqrstuvwyz", c) == NULL;
}

What happens if the user enters a lowercase accented letter, such as 'á'
(which may or may not show up on your system properly, but is an accented
'a' here)?

 

[Dan Pop]

Huh, what can he mean here? And, the OP is not even able to type
an 'x'. The question is, at least a bit, off-topic too. Sorry

More than a bit. It's downright off-topic.

guys, and especially a sorry to the OP; I'll try not to do it again.


This point 3. has a causality problem. If you're able to
run a C compiler, a C compiler that is able to print, then
I guess stdio.h will be close enough.

I'm afraid I can't make any sense out of your incoherent statement.

Dan

 

[Dan Pop]

Now this question is perhaps off-topic for comp.lang.c, but I don't
understand *why* you can't use UCNs for members of the basic character
set. What is the rationale behind this constraint?

I have no clue. Try the C99 rationale or ask in comp.std.c. The relevant
chapter and verse is:

6.4.3 Universal character names
....
Constraints

2 A universal character name shall not specify a character whose
short identifier is less than 00A0 other than 0024 ($), 0040 (@),
or 0060 (`), nor one in the range D800 through DFFF inclusive. 61)

____________________

61) The disallowed characters are the characters in the basic
character set and the code positions reserved by ISO/IEC 10646
for control characters, the character DELETE, and the S-zone
(reserved for use by UTF-16).

Dan