| View previous topic :: View next topic |
| Author |
Message |
Guest
|
 Posted: Fri Jul 11, 2008 4:49 pm Post subject: 64-bit mode |
 |
|
So i am going to develope a simple os only for my use. And now my
question: I've got 64bit AMD processor, so I could develope it in
64bit mode. So is it worth to develope it 64 bit, will 32 bit be out
of date in future?
Is there a good tutorial on the internet how to establish 64 bit mode
and develope os in 64 bit mode? |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
Rod Pemberton
Guest
|
| Posted: Sat Jul 12, 2008 11:02 am Post subject: Re: 64-bit mode |
|
|
<matematik@mail386.com> wrote in message
news:8273e9ae-2332-48c8-a95e-4fa166a0ef77@d45g2000hsc.googlegroups.com...
| Quote: |
So i am going to develope a simple os only for my use. And now my
question: I've got 64bit AMD processor, so I could develope it in
64bit mode. So is it worth to develope it 64 bit, will 32 bit be out
of date in future?
|
If I were starting today, I'd develop for 64-bit x86. On percentage market
share, all other cpu's are effectively _dead_ compared to x86. But, if you
take a specific cpu market, say embedded devices, you may find some other
cpu platform, such as the ARM, dominates. 64-bits has been available for
five (AMD) to seven (Intel) years now on x86. It's possible that even
larger modes may become available for similar reasons (VLIW and EPIC) that
Intel/AMD saw need to bring 64-bits to the market... Support for 64-bits is
likely to improve gradually. Support for and usefulness of 32-bit code is
likely to decline gradually. Personally, I haven't seen any mention of a
really important code advantage for using 64-bits instead of 32-bits. So,
32-bits might be fine to develop today, if you can easily convert the code
to 64-bits. E.g., 1) use assembly macro's which can implement both 32-bit
and 64-bit code or 2) use a C compiler that supports both. Some 16-bit code
is still used in the BIOS, but it may be phased out by EFI and/or UEFI which
is implemented in interpretable code.
VLIW
http://en.wikipedia.org/wiki/Very_long_instruction_word
EPIC
http://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing
Rod Pemberton |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Guest
|
| Posted: Sat Jul 12, 2008 12:13 pm Post subject: Re: 64-bit mode |
|
|
So its very likely that i will dvelope 64 bit os. Now I 've got a few
questions: Is there a good example code of switching to 64-bit mode?
Can i go directly to 64 bit mode, or i have to enter PMode first? Does
Bochs support 64 bit mode? |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Wolfgang Kern
Guest
|
| Posted: Sat Jul 12, 2008 8:21 pm Post subject: Re: 64-bit mode |
|
|
matematik... asked:
| Quote: |
So its very likely that i will dvelope 64 bit os. Now I 've got a few
questions: Is there a good example code of switching to 64-bit mode?
|
Yes, search in the AMD docs, there is everthing explained in deep detail.
| Quote: |
Can i go directly to 64 bit mode, or i have to enter PMode first?
|
Long mode needs paging enabled and this needs PM.
| Quote: |
Does Bochs support 64 bit mode?
|
Dunno, haven't heard about it yet.
__
wolfgang |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Alexei A. Frounze
Guest
|
| Posted: Sun Jul 13, 2008 2:41 am Post subject: Re: 64-bit mode |
|
|
On Jul 12, 3:21 pm, "Maxim S. Shatskih" <ma...@storagecraft.com>
wrote:
| Quote: |
If I were starting today, I'd develop for 64-bit x86.
This is called "x64", the acronym "x86" is never used on 64bit stuff.
cpu platform, such as the ARM, dominates. 64-bits has been available for
five (AMD) to seven (Intel) years now on x86.
Vice versa. x64 originated at AMD and then borrowed at Intel.
|
Did Rod mean Itanium? It used to have x86 support.
Alex |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Maxim S. Shatskih
Guest
|
| Posted: Sun Jul 13, 2008 3:21 am Post subject: Re: 64-bit mode |
|
|
| Quote: |
If I were starting today, I'd develop for 64-bit x86.
|
This is called "x64", the acronym "x86" is never used on 64bit stuff.
| Quote: |
cpu platform, such as the ARM, dominates. 64-bits has been available for
five (AMD) to seven (Intel) years now on x86.
|
Vice versa. x64 originated at AMD and then borrowed at Intel.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Alexei A. Frounze
Guest
|
| Posted: Sun Jul 13, 2008 8:44 am Post subject: Re: 64-bit mode |
|
|
On Jul 13, 1:24 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
....
| Quote: |
Alexei, am I experiencing deja vu?
(i.e., I'd swear I corrected Maxim at least twice previously on same
nomeclature... after you pointed out my mistake w/IA-64 about a year ago.
Whats that... every four months?)
|
I don't know.  All I know intel first made itanium with x86 support,
then AMD did a better 64-bit x86-compatible CPU which then intel
implemented too. So, I just expressed a conjecture about mixing up
entirely different 64-bit CPUs...
Alex |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Rod Pemberton
Guest
|
| Posted: Sun Jul 13, 2008 11:03 am Post subject: Re: 64-bit mode |
|
|
"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:g5baom$13bh$1@news.mtu.ru...
| Quote: |
If I were starting today, I'd develop for 64-bit x86.
This is called "x64", the acronym "x86" is never used on 64bit stuff.
|
Really?
Sandpile.org uses AA-64 and x86-64.
Wikipedia uses x86-64, AMD64, Intel64, EM64T.
If one is to believe Wikipedia, AMD64 is AMD's proper name and Intel64 is
Intel's proper name.
| Quote: |
cpu platform, such as the ARM, dominates. 64-bits has been available
for
five (AMD) to seven (Intel) years now on x86.
Vice versa.
|
A polite, wrong...
I didn't say "x64". I said "64-bits". Intel introduced 64-bits prior to
AMD: Itanium (e.g., IA-64). Wikipedia records the processor release dates
for Intel's IA-64 (Itanium) as 2001, AMD's AA-64 as 2003, and Intel64
(Intel's AA-64 equivalent) as 2004.
| Quote: |
x64 originated at AMD
|
True.
| Quote: |
and then borrowed at Intel.
|
True for AA-64 ("x64") architecture.
Alexei, am I experiencing deja vu?
(i.e., I'd swear I corrected Maxim at least twice previously on same
nomeclature... after you pointed out my mistake w/IA-64 about a year ago.
Whats that... every four months?)
Rod Pemberton |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Maxim S. Shatskih
Guest
|
| Posted: Sun Jul 13, 2008 11:03 am Post subject: Re: 64-bit mode |
|
|
| Quote: |
Vice versa. x64 originated at AMD and then borrowed at Intel.
Did Rod mean Itanium? It used to have x86 support.
|
Itanium is not x64, it is absolutely different, and only had x86 emulation
(slow).
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Brendan
Guest
|
| Posted: Mon Jul 14, 2008 1:07 pm Post subject: Re: 64-bit mode |
|
|
Hi,
On Jul 13, 12:21 am, "Wolfgang Kern" <nowh...@never.at> wrote:
| Quote: |
matematik... asked:
Can i go directly to 64 bit mode, or i have to enter PMode first?
Long mode needs paging enabled and this needs PM.
|
To switch to long mode, you *don't* need an intermediate protected
mode step.
The steps I used (starting from real mode) are:
1) Build paging structures (PML4, PDPT, PD and PTs)
2) Enable PAE in CR4
3) Set CR3 so it points to the PML4
4) Enable long mode in the EFER MSR
5) Enable paging and protected mode at the same time (activate long
mode)
6) Load a GDT
7) Do a "far jump" to some 64 bit code
This goes directly from real mode to the "compatibility sub-mode of
long mode" with the final far jump switching to the "64-bit sub-mode
of long mode". Basically you do as much as possible in real mode, then
enable paging and protected mode at the same time while long mode is
enabled to activate long mode.
For more information see http://wiki.osdev.org/Long_Mode#Entering_Long_Mode_directly
Or, see the example code at http://wiki.osdev.org/Entering_Long_Mode_Directly
| Quote: |
Does Bochs support 64 bit mode?
|
Yes!
Cheers,
Brendan |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Wolfgang Kern
Guest
|
| Posted: Tue Jul 15, 2008 2:25 am Post subject: Re: 64-bit mode |
|
|
Brendan corrected:
| Quote: |
Long mode needs paging enabled and this needs PM.
To switch to long mode, you *don't* need an intermediate protected
mode step.
The steps I used (starting from real mode) are:
1) Build paging structures (PML4, PDPT, PD and PTs)
2) Enable PAE in CR4
3) Set CR3 so it points to the PML4
4) Enable long mode in the EFER MSR
5) Enable paging and protected mode at the same time (activate long
mode)
6) Load a GDT
7) Do a "far jump" to some 64 bit code
This goes directly from real mode to the "compatibility sub-mode of
long mode" with the final far jump switching to the "64-bit sub-mode
of long mode". Basically you do as much as possible in real mode, then
enable paging and protected mode at the same time while long mode is
enabled to activate long mode.
For more information see
http://wiki.osdev.org/Long_Mode#Entering_Long_Mode_directly
Or, see the example code at
http://wiki.osdev.org/Entering_Long_Mode_Directly |
| Quote: |
Does Bochs support 64 bit mode?
Yes!
|
Good to know that this is possible even CPU manuals state it different,
but I'd like to see my pagetables above the 1.MB.
Thanks Brendan,
__
wolfgang |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Rod Pemberton
Guest
|
| Posted: Tue Jul 15, 2008 11:05 am Post subject: Re: 64-bit mode |
|
|
"Wolfgang Kern" <nowhere@never.at> wrote in message
news:g5gjg6$ulj$2@newsreader2.utanet.at...
| Quote: |
Brendan corrected:
Long mode needs paging enabled and this needs PM.
To switch to long mode, you *don't* need an intermediate protected
mode step.
The steps I used (starting from real mode) are:
1) Build paging structures (PML4, PDPT, PD and PTs)
2) Enable PAE in CR4
3) Set CR3 so it points to the PML4
4) Enable long mode in the EFER MSR
5) Enable paging and protected mode at the same time (activate long
mode)
6) Load a GDT
7) Do a "far jump" to some 64 bit code
This goes directly from real mode to the "compatibility sub-mode of
long mode" with the final far jump switching to the "64-bit sub-mode
of long mode". Basically you do as much as possible in real mode, then
enable paging and protected mode at the same time while long mode is
enabled to activate long mode.
Good to know that this is possible even CPU manuals state it different,
but I'd like to see my pagetables above the 1.MB.
....
even CPU manuals state it different,
|
By that, I take it you were referring to Brendan's statement:
| Quote: |
enable paging and protected mode at the same time
|
Yeah, I thought the manuals distinctly said NOT to enable paging until AFTER
protected mode was completely enabled... Was that pre-64 only?
Rod Pemberton |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Wolfgang Kern
Guest
|
| Posted: Tue Jul 15, 2008 11:05 am Post subject: Re: 64-bit mode |
|
|
Rod Pemberton asked:
....
| Quote: |
To switch to long mode, you *don't* need an intermediate protected
mode step.
....
...even CPU manuals state it different,
By that, I take it you were referring to Brendan's statement:
enable paging and protected mode at the same time
Yeah, I thought the manuals distinctly said NOT to enable paging
until AFTER protected mode was completely enabled...
Was that pre-64 only?
|
it is also mentioned in the AMD64 docs. I havn't checked if this
may also work for not-long 32-bit modes or on 32-bit CPUs.
__
wolfgang |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Brendan
Guest
|
| Posted: Tue Jul 15, 2008 11:38 pm Post subject: Re: 64-bit mode |
|
|
Hi,
On Jul 15, 6:25 am, "Wolfgang Kern" <nowh...@never.at> wrote:
| Quote: |
Good to know that this is possible even CPU manuals state it different,
but I'd like to see my pagetables above the 1.MB.
|
I like to see my page tables above 4 GB (where possible), as RAM above
4 GB is the "least useful" - ie. can't be used by ISA DMA; or 32-bit
PCI devices and 64-bit PCI devices stuck behind a dodgy (32-bit only)
PCI->PCI bridge (unless an I/O MMU is present and your OS supports
using it for this purpose).
I also like to see paging structures that are accessed by CPUs in a
specific NUMA domain using RAM that's "close" to that NUMA domain.
However, typically my boot code becomes the first process (with "less
than optimal" paging structures because the initial address space is
constructed before the kernel's memory management is configured/
working), then other processes are started (with "optimal" paging
structures because these address spaces are constructed after the
kernel's memory management is configured/working), then the first
process is terminated. Basically the paging structures used during
boot are temporary and it doesn't matter a lot where the RAM comes
from...
On Jul 15, 6:54 pm, "Wolfgang Kern" <nowh...@never.at> wrote:
| Quote: |
Rod Pemberton asked:
Yeah, I thought the manuals distinctly said NOT to enable paging
until AFTER protected mode was completely enabled...
Was that pre-64 only?
|
When I first wrote this code (about 3 and a half years ago now) there
was an AMD document describing long mode that led me to believe it was
possible (or, nothing in that document indicated that it might not be
possible). A more recent AMD programmer's manual contradicted things
said in the previous AMD document. Testing on AMD CPUs showed that
AMD's earlier document was more accurate.
Also, at the time Intel had updated their programmer's manual to
include long mode, and that manual also contradicted things said in
the previous AMD document. I got the feeling that a lot of the
additions in Intel's manual were derived from AMD's manual (rather
than being derived from the design of the silicon) - similar
structure, similar wording, similar example code. Testing on Intel
CPUs showed that AMD's earlier document was more accurate.
Basically, IMHO it seems possible that one person writing one piece of
documentation may have used "imprecise wording" - the sort of wording
that doesn't adequately distinguish between phrases like "A must
happen before B" and "A must not happen after B" (which seem so
similar but are NOT the same) - and this "imprecise wording" may have
influenced later documentation.
Back then I also tried to get an explanation from AMD about the
contradictions on their developer forums (asking which documentation
was correct, their earlier documentation or their later
documentation). This didn't really lead to anything.
Basically, my "real mode direct to long mode" code complies with my
mental image of the inner workings of a CPU (in the same way that
"unreal mode" complies with my mental image of the inner workings of a
CPU), and testing has shown this mental image to be correct.
So, on one side we've got some documentation saying "it can't be
done"; and on the other side we've got one earlier document saying it
can be done, plus code and silicon that proves it can be done, plus my
"mental image".. :-)
My original (3 and a half year old) opinion remains the same - it
works until someone can prove it doesn't (despite what any
documentation says).
Cheers,
Brendan |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Alexei A. Frounze
Guest
|
| Posted: Wed Jul 16, 2008 10:28 am Post subject: Re: 64-bit mode |
|
|
On Jul 16, 1:43 am, "Wolfgang Kern" <nowh...@never.at> wrote:
| Quote: |
Brendan wrote:
Good to know that this is possible even CPU manuals state it different,
but I'd like to see my pagetables above the 1.MB.
... Basically the paging structures used during
boot are temporary and it doesn't matter a lot where the RAM comes
from...
Yes, this makes sense.
[about CPU manuals... ]
...
My original (3 and a half year old) opinion remains the same - it
works until someone can prove it doesn't (despite what any
documentation says).
Right, we may always find things working which aren't documented
because even the chip developers may not know all coincident
behaviour beside strict defined functionalities.
__
wolfgang
|
Possible, but not necessarily. Not documenting something clearly and
discouraging from doing certain things has other uses:
1. fewer guarantees -> less support
2. freedom to change things later
3. covering up bugs (doesn't always work, especially retrospectively)
4. making competitors' lives harder
What's interesting is that often times not only competitors struggle
with some obscure and ambiguous things in the documentation, others do
too (if there's only one set of documentation for everyone) and that
may actually incur more support requests (unless people turn straight
to reverse engineering in those gray areas).
Alex |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
125 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
