understanding physical address usage

Some devices memory are mapped on the main memory and this provides an
easy way to talk to them. So these mappings must be taking addresses
that I could use for data, right?

I'm trying to understand what addresses are available to me once I
account for all hardware needs. Let's say I want to write a kernel,
and so I need to think of where kernel will be at, and what else is
available for usage.

My whole physical memory goes from 0 to 2^32 - 1. My first question
here is regarding the i/o address space. Citations are from intel's
manual volume 1, basic architecture.

13.3 I/O ADDRESS SPACE

The processor’s I/O address space is separate and distinct from
the physical-memory address space. The I/O address space consists
of 2^16 (64K) individually addressable 8-bit I/O ports, numbered 0
through FFFFH. I/O port addresses 0F8H through 0FFH are
reserved. Do not assign I/O ports to these addresses. The result
of an attempt to address beyond the I/O address space limit of
FFFFH is implementation-specific; see the Developer’s Manuals for
specific processors for more details.

So, these 64K do not eat up my main memory, correct? However,
memory-mapped i/o do, right? So I'd like to find out what sort of
addresses the various hardware parts need and see what I am left with
for kernel code and data, and user code and data.

Any pointers? Thanks very much.

In article ,
(Daniel Chicayban Bastos) wrote:

Some devices memory are mapped on the main memory and this provides an
easy way to talk to them. So these mappings must be taking addresses
that I could use for data, right?

Absolutely.

You need to start by looking up concepts like "DMA controller" and the
PCI bus specification.

So, these 64K do not eat up my main memory, correct?

Indeed.

However, memory-mapped i/o do, right?

Yes. It is considered worthwhile because port i/o is slow, whereas
memory-mapped i/o can be accessed much faster. Devices like network
cards and video cards can easily need more than 64Kbytes of space all by
themselves.

So I'd like to find out what sort of addresses the various hardware
parts need and see what I am left with for kernel code and data, and
user code and data.

Assuming you are designing a kernel to run on PC-type hardware, the
answer will be "Much the same as Windows and Linux get to use on the
same hardware". There aren't many memory addresses that are reserved or
pre-assigned by the processor itself - startup vectors, interrupt
vectors, and so on - but there are a lot of conventions followed by
PC-compatible hardware, and falling in line with them will make your life
a great deal easier.

Have you ever done any low-level programming of hardware? Device
drivers, systems without virtual addressing, that kind of thing? If not,
I'd suggest you gather some such experience before you start trying to
write an OS kernel from scratch.

Designing a kernel for 32-bit addressing, as you seem to imply, may be
useful, depending on your intended purposes, but will immediately
deprive it of being in any way leading-edge. 32-bit is legacy technology
now; 64-bit is the future.

What are you hoping to get out of this project?

--
John Dallman
"C++ - the FORTRAN of the early 21st century."

Daniel Chicayban Bastos wrote:
13.3 I/O ADDRESS SPACE

The processor’s I/O address space is separate and distinct from
the physical-memory address space. The I/O address space consists
of 2^16 (64K) individually addressable 8-bit I/O ports, numbered 0
through FFFFH. I/O port addresses 0F8H through 0FFH are
reserved. Do not assign I/O ports to these addresses. The result
of an attempt to address beyond the I/O address space limit of
FFFFH is implementation-specific; see the Developer’s Manuals for
specific processors for more details.

These are also known as i/o ports, because each of the addresses in this
map were known as port registers.

So, these 64K do not eat up my main memory, correct? However,
memory-mapped i/o do, right? So I'd like to find out what sort of
addresses the various hardware parts need and see what I am left with
for kernel code and data, and user code and data.


There's two ways hardware can use up your memory map. One way is the way
video cards use it up, by reserving a part of the memory map and putting
its own ram in that location. They call this an aperture. The memory
addresses reserved by this method typically a fixed in size and location
(though often adjustable prior to boot with the BIOS setup screens).

Another way devices can use memory is to time-share the system memory.
This is how DMA and bus-mastering devices work. The device locks down a
part of the memory making it inaccessible even to the processor during
that time, and transfer data in and out. Once that operation is done,
then it releases the memory and the CPU can go in there and operate on
that data. It frees up the CPU from having to do the menial and
time-consuming task of transferring data for a device, by letting the
device itself do the transferal. The memory addresses that DMA can use
span the entire memory range, since they don't lock down the whole
memory for the complete duration of time that the computer is on.

Yousuf Khan

In article ,
wrote:

In article ,
(Daniel Chicayban Bastos) wrote:

So I'd like to find out what sort of addresses the various hardware
parts need and see what I am left with for kernel code and data, and
user code and data.

Assuming you are designing a kernel to run on PC-type hardware, the
answer will be "Much the same as Windows and Linux get to use on the
same hardware". There aren't many memory addresses that are reserved or
pre-assigned by the processor itself - startup vectors, interrupt
vectors, and so on - but there are a lot of conventions followed by
PC-compatible hardware, and falling in line with them will make your life
a great deal easier.

Have you ever done any low-level programming of hardware? Device
drivers, systems without virtual addressing, that kind of thing? If not,
I'd suggest you gather some such experience before you start trying to
write an OS kernel from scratch.

No, no. Firsttimer.

Designing a kernel for 32-bit addressing, as you seem to imply, may be
useful, depending on your intended purposes, but will immediately
deprive it of being in any way leading-edge. 32-bit is legacy technology
now; 64-bit is the future.

What are you hoping to get out of this project?

Yeah, I was thinking of that myself. I don't have a 64-bit system
though, and my intention is fun. I'm not even decided I will really
write anything; let's see what happens. For now I'm just investigating
things. I looked into the cpuid instruction to see how to identify my
processor, and it all began.

But I guess I found the right newsgroups for intel x86? :-)

In article ,
(Daniel Chicayban Bastos) wrote:

What are you hoping to get out of this project?
Yeah, I was thinking of that myself. I don't have a 64-bit system
though, and my intention is fun. I'm not even decided I will really
write anything; let's see what happens. For now I'm just investigating
things. I looked into the cpuid instruction to see how to identify my
processor, and it all began.

Unless you are remarkably tenacious, fun is the best you can expect to
achieve starting from here. I'd advise starting with some simpler kind
of system than a modern PC - they're pretty complicated. However, it's
not obvious what that might be; there aren't many simple consumer
computers any more, like the Sinclair Spectrum or Atari ST.

You might do better to start with Linux, learn to program on that a bit,
and then start to look at the boot-loaders, kernel and so on. The source
is all available. Note that you will need to multi-boot your computer,
since it will be a long time before your own OS will do anything useful.
And if you're writing low-level disk code such as you'll need to start
an OS, a separate machine for the job really is advisable.

But I guess I found the right newsgroups for intel x86? :-)

This newsgroup usually deals with things like setting up Intel
motherboards and device drivers, rather than programming complicated
software.

--
John Dallman
"C++ - the FORTRAN of the early 21st century."