public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* hex addresses in setup.S
@ 2002-01-16 19:13 Chris Swiedler
  2002-01-16 20:03 ` H. Peter Anvin
  2002-01-16 20:44 ` Richard B. Johnson
  0 siblings, 2 replies; 3+ messages in thread
From: Chris Swiedler @ 2002-01-16 19:13 UTC (permalink / raw)
  To: Linux-Kernel

Why does setup.S define the default system load address as 0x1000, and the
comment on the line explain this to be 0x10000(and gives the decimal
translation of 65536, so it's not a typo)? This seems to be true for several
addresss (0x9000 = 0x90000, etc). I'm sure there's something simple I'm
missing...what is it?

TIA,
chris


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: hex addresses in setup.S
  2002-01-16 19:13 hex addresses in setup.S Chris Swiedler
@ 2002-01-16 20:03 ` H. Peter Anvin
  2002-01-16 20:44 ` Richard B. Johnson
  1 sibling, 0 replies; 3+ messages in thread
From: H. Peter Anvin @ 2002-01-16 20:03 UTC (permalink / raw)
  To: linux-kernel

Followup to:  <BJEJJDPJOCEPDBLPFDKJCEACCCAA.ceswiedler@mindspring.com>
By author:    "Chris Swiedler" <ceswiedler@mindspring.com>
In newsgroup: linux.dev.kernel
>
> Why does setup.S define the default system load address as 0x1000, and the
> comment on the line explain this to be 0x10000(and gives the decimal
> translation of 65536, so it's not a typo)? This seems to be true for several
> addresss (0x9000 = 0x90000, etc). I'm sure there's something simple I'm
> missing...what is it?
> 

In real mode:

linear_address := (segment << 4) + offset

Those addresses are "segment" addresses, with (implied) offset == 0.
These kinds of addresses are sometimes referred to as "paragraph
addresses" (paragraph being bigger than words but smaller than pages,
I guess.)

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: hex addresses in setup.S
  2002-01-16 19:13 hex addresses in setup.S Chris Swiedler
  2002-01-16 20:03 ` H. Peter Anvin
@ 2002-01-16 20:44 ` Richard B. Johnson
  1 sibling, 0 replies; 3+ messages in thread
From: Richard B. Johnson @ 2002-01-16 20:44 UTC (permalink / raw)
  To: Chris Swiedler; +Cc: Linux-Kernel

On Wed, 16 Jan 2002, Chris Swiedler wrote:

> Why does setup.S define the default system load address as 0x1000, and the
> comment on the line explain this to be 0x10000(and gives the decimal
> translation of 65536, so it's not a typo)? This seems to be true for several
> addresss (0x9000 = 0x90000, etc). I'm sure there's something simple I'm
> missing...what is it?
> 
> TIA,
> chris

In Intel real mode, an address is represented as SEGMENT:OFFSET.
The segment is a 16-byte chunk called a 'paragraph'. There are
many ways of representing an address in real mode. Just take
the absolute memory location and divide it by 16. The quotent
is the segment and the remainder is the offset. This will
give you the lowest possible offset.  However, a maximum-value
address can be represented (65536 / 16) -1 = 4095 different ways!

If the segment has been set to 0x9000 as in setup.S, then the
absolute address is 0x9000 * 0x10 = 0x90000. This means that
0x9000:0000 points to 0x00090000 absolute, while 0x9000:0001
would point to 0x00090001 absolute.

The segment-part of the address goes into a segment register
such as CS, DS, ES, or SS, and your addressing then becomes
relative to that segment register. For instance, if you did:

	destination <--- source
	mov	ax,1000h
	mov	ds,ax
	mov	bx, 2
	mov	ax,[bx]

... the result will be whatever 16-bit word was at absolute location
0x100002 in your ax register.

The complication of real-mode starts to make itself known when the
registers are set to their maximum values:

	0xffff:0xffff

This gives you (65535 * 16) + 65535 = 1114095 ... the 1 megabyte
                ^^^^^^^^^^    ^^^^^
                max segment   max offset
"barrier". That's why 32-bit Operating Systems were developed for
Intel machines. The next barrier was 0xffffffff, but by playing
with the same kind of page-register schemes that worked in real-mode,
we can now access physical memory that exists at a greater offset
than 0xffffffff, however, the maximum virtual offset per process will
remain at 0xffffffff as long as we have 32-bit addressing.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-01-16 20:43 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-01-16 19:13 hex addresses in setup.S Chris Swiedler
2002-01-16 20:03 ` H. Peter Anvin
2002-01-16 20:44 ` Richard B. Johnson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox