is there a difference between reading some code into memory
and executing some code into memory ?
do you have to load stuff in memory before you can execute it ?
i'm obviously a begineer...
loading and reading - differences
-
Schol-R-LEA
RE:loading and reading - differences
>On 2002-05-14 23:27:09, keyboard_ninja wrote:
>is there a difference between reading some code into memory
>and executing some code into memory ?
>
>do you have to load stuff in memory before you can execute it ?
>i'm obviously a begineer...
The simple answers are, yes and yes. A bit more
detail is probably called for, however.
At boot time, the BIOS does, in fact, load some
code into memory for you; specifically, the code
in the boot sector of the boot disk (physical
sector zero in the case of a floppy; the zero
sector of the active partition, in the case of a
hard disk). This 512 byte snippet of absolute
machine code, called the bootstrap loader, is
loaded into memory location 0x07C00. This code,
in turn, must load into memory the next stage of
the operating system; what that is, and how it
does it, is up to the OS designer. While the BIOS
disk functions are available to you, these only
provide the minimum support for reading and
writing raw sectors; you have to write your own
code to do the loading itself, which will depend
on the disk format, the material loaded, and
other factors that you will have to determine
yourself in the course of OS design.
The main things you'll need to determine are,
where is the code getting loaded from, where will
it be loaded into, how large will it be. Again,
this will be absolute machine code (unless you
somehow managed to squeeze a mini-filesystem and
relocating loader into the bootstrap, in which
case congratulations on your assembly language
coding skills), so you will need to know the
sector and offset that it will be loaded to at
assemble/compile time.
Because 512 bytes isn't exactly a copious amount
of room for your startup code, it is usually wise
to load the OS in a two step process, in which
the code read into memory by the boot loader
reads in the next stage of the OS (and handles
any needed setup work, such as checking the
processor type and switching to protected mode).
Don't spend too much time on the issue of boot
loading; it will only distract you from actually
writing your kernel. A suitable boot loader that
will work on all hardware reliably is a hell of a
lot of work; many a promising OS project
(snicker) has foundered on those shoals. While it
is a good idea to experiment with boot loading to
familiarize yourself with the process, in actual
practice you will almost certainly want to use an
existing Multiboot compatible loader like GRUB to
save yourself headaches. If you want more info on
the boot process (and you will), consult any of
the many FAQs and how-tos on the topic in this
web sites 'links' page (there is a link to it at
the top of this page).
Once an OS is running, loading code into and out
of memory is, of course, one of it's primary
operations. Up until now, I've been talking about
'absolute' loading: the code is actual machine
instructions, and gets loaded into a fixed
location in memory. This will always be the case
for the boot loader (which is loaded by the BIOS
firmware), and generally will be the case with
whatever will be loaded by the boot loader. Once
you get past that point, however, you will (in
all but the simplest systems) be loading a
relocatable object format of some sort. What this
means is, rather than having raw machine code,
the file contains the information needed to
generate the final loaded code on the fly; what
this usually means is that variables, labels,
etc. are stored relative to the entry point of
the code, and the final values clculated and
inserted at run time. This means that a given
program need not be loaded into a fixed location,
which may or may not already be in use by another
program. There are more issues which are too
complex to bring up here; the book _Linkers and
Loaders_ by John Levine (ISBN 1-55860-496-0) is
probably the best reference on the topic, as most
OS books, sadly, give short shrift to the issue.
>is there a difference between reading some code into memory
>and executing some code into memory ?
>
>do you have to load stuff in memory before you can execute it ?
>i'm obviously a begineer...
The simple answers are, yes and yes. A bit more
detail is probably called for, however.
At boot time, the BIOS does, in fact, load some
code into memory for you; specifically, the code
in the boot sector of the boot disk (physical
sector zero in the case of a floppy; the zero
sector of the active partition, in the case of a
hard disk). This 512 byte snippet of absolute
machine code, called the bootstrap loader, is
loaded into memory location 0x07C00. This code,
in turn, must load into memory the next stage of
the operating system; what that is, and how it
does it, is up to the OS designer. While the BIOS
disk functions are available to you, these only
provide the minimum support for reading and
writing raw sectors; you have to write your own
code to do the loading itself, which will depend
on the disk format, the material loaded, and
other factors that you will have to determine
yourself in the course of OS design.
The main things you'll need to determine are,
where is the code getting loaded from, where will
it be loaded into, how large will it be. Again,
this will be absolute machine code (unless you
somehow managed to squeeze a mini-filesystem and
relocating loader into the bootstrap, in which
case congratulations on your assembly language
coding skills), so you will need to know the
sector and offset that it will be loaded to at
assemble/compile time.
Because 512 bytes isn't exactly a copious amount
of room for your startup code, it is usually wise
to load the OS in a two step process, in which
the code read into memory by the boot loader
reads in the next stage of the OS (and handles
any needed setup work, such as checking the
processor type and switching to protected mode).
Don't spend too much time on the issue of boot
loading; it will only distract you from actually
writing your kernel. A suitable boot loader that
will work on all hardware reliably is a hell of a
lot of work; many a promising OS project
(snicker) has foundered on those shoals. While it
is a good idea to experiment with boot loading to
familiarize yourself with the process, in actual
practice you will almost certainly want to use an
existing Multiboot compatible loader like GRUB to
save yourself headaches. If you want more info on
the boot process (and you will), consult any of
the many FAQs and how-tos on the topic in this
web sites 'links' page (there is a link to it at
the top of this page).
Once an OS is running, loading code into and out
of memory is, of course, one of it's primary
operations. Up until now, I've been talking about
'absolute' loading: the code is actual machine
instructions, and gets loaded into a fixed
location in memory. This will always be the case
for the boot loader (which is loaded by the BIOS
firmware), and generally will be the case with
whatever will be loaded by the boot loader. Once
you get past that point, however, you will (in
all but the simplest systems) be loading a
relocatable object format of some sort. What this
means is, rather than having raw machine code,
the file contains the information needed to
generate the final loaded code on the fly; what
this usually means is that variables, labels,
etc. are stored relative to the entry point of
the code, and the final values clculated and
inserted at run time. This means that a given
program need not be loaded into a fixed location,
which may or may not already be in use by another
program. There are more issues which are too
complex to bring up here; the book _Linkers and
Loaders_ by John Levine (ISBN 1-55860-496-0) is
probably the best reference on the topic, as most
OS books, sadly, give short shrift to the issue.
-
Schol-R-LEA
RE:loading and reading - differences
>On 2002-05-14 23:27:09, keyboard_ninja wrote:
>is there a difference between reading some code into memory
>and executing some code into memory ?
>
>do you have to load stuff in memory before you can execute it ?
>i'm obviously a begineer...
It occurs to me that while I answered your second
question in detail, I'd neglected the second.
Allow me to correct that oversight now.
Loading a program into memory means exactly that:
copying the code from secondary storage (i.e.,
disk) into a location in memory. In most cases,
that also means calculating relocations and
making any linkages necessary for the program to
run correctly.
Executing the program, then, is simply the matter
of jumping to the first instruction of the code
after it has been loaded. In principle, that is;
just what events take place depend on the OS.
However, in the case of a boot loader it is
generally not much more than a FAR JMP and some
segment juggling.
This only scratches the surface, but you should
get the drift of things. See the _Linkers and
Loaders_ book for advanced study, but any OS
design book should give the basics.
>is there a difference between reading some code into memory
>and executing some code into memory ?
>
>do you have to load stuff in memory before you can execute it ?
>i'm obviously a begineer...
It occurs to me that while I answered your second
question in detail, I'd neglected the second.
Allow me to correct that oversight now.
Loading a program into memory means exactly that:
copying the code from secondary storage (i.e.,
disk) into a location in memory. In most cases,
that also means calculating relocations and
making any linkages necessary for the program to
run correctly.
Executing the program, then, is simply the matter
of jumping to the first instruction of the code
after it has been loaded. In principle, that is;
just what events take place depend on the OS.
However, in the case of a boot loader it is
generally not much more than a FAR JMP and some
segment juggling.
This only scratches the surface, but you should
get the drift of things. See the _Linkers and
Loaders_ book for advanced study, but any OS
design book should give the basics.