Re: 64-bit compile? - SOLVED
On Nov 15, 2007 7:16 AM, Bryan J. Smith [EMAIL PROTECTED] wrote: Hence why I wrote a brief blog article here: 'What is x86-64? Long Mode memory model ...' http://thebs413.blogspot.com/2005/10/what-is-x86-64-long-mode-memory-model.html One thing to correct, otherwise it looks fine: 'Long Mode also offers a 48-bit (256TiB) Flat address model by using the 16-bit segment register as bits 32-47 to the 32-bit offset register of bits 0-31. This is the new memory model that programs and libraries may use.' No, segment registers are large ignored in long mode! What happens is that you have 64-bit registers RAX, RBX, RCX etc., and using those you can address 48-bits (bits 48-63 are not used). In fact there is a 2^47 byte sized positive user address space from 0 to 2^47-1 and a 2^47 sized negative kernel address space from 2^64-2^47 to 2^64-1. As for segment registers, only fs and gs are used, and each have a 64-bit base address associated to them; the bits of fs and gs themselves are independent of bits 32-47 of the final address. In a nutshell, 48-bit (PAE 52-bit) addressed Long Mode is focused on being 32-bit (PAE 36-bit) i486 TLB (i686 PAE) compatible. But there is no reason why it can't support i386 Virtual86 modes either. The patch allows Virtual86 programs to run on a Long Mode kernel just as fast as they do on i486 or i686 PAE kernels. Long mode does not support running i386 Virtual86 modes. That's how the chip works. In fact the chip has three modes: real legacy long legacy (what we used to simply call protected mode) has three submodes: 16-bit protected, 32-bit protected, and Virtual86 long also has three submodes: 16-bit protected, 32-bit protected, and 64-bit protected: note that V86 is missing! It is easy to switch between submodes, but harder to switch between modes; interrupt handling in particular is different. So the referenced kernel patch needs to shut off long mode, disable paging, enter legacy mode, re-enable paging, and then enter virtual-86 mode. Everytime an interrupt comes in, it needs to do the reverse -- nothing goes as easy as automatically resetting a flag as with a legacy mode (32-bit) kernel. Indeed the similarities between 52-bit and 36-bit PAE make it possible to not having to convert page tables though. Hope that clarifies some bits, Bart - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 64-bit compile? - SOLVED
I raised this issue on the Fedora mailing list as well as here and have received a very interesting response. See here: https://www.redhat.com/archives/fedora-list/2007-November/msg02329.html Mr. Boszormenyi apparently needed to apply a patch to the dosemu source tree in order to get dosemu to compile on his x86_64 machine. I, on the other hand, didn't need to do this and it still compiled for me and appears to work fine in my (so far, limited) testing. As this is substantially beyond my understanding, I would appreciate any feedback or information that anyone here would care to share with me. This whole x86_64 stuff is an entirely new adventure for me. -- MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 64-bit compile? - SOLVED
Frank Cox [EMAIL PROTECTED] wrote: As this is substantially beyond my understanding, The first chapter in the AMD x86-64 Programmer's Manual has some great tables on memory model support, although it does lack some more detailed explanation for the unfamilar with 8086, i486 TLB, i686 PAE, etc... segmenting, page tables, etc... I would appreciate any feedback or information that anyone here would care to share with me. This whole x86_64 stuff is an entirely new adventure for me. Hence why I wrote a brief blog article here: 'What is x86-64? Long Mode memory model ...' http://thebs413.blogspot.com/2005/10/what-is-x86-64-long-mode-memory-model.html In a nutshell, 48-bit (PAE 52-bit) addressed Long Mode is focused on being 32-bit (PAE 36-bit) i486 TLB (i686 PAE) compatible. But there is no reason why it can't support i386 Virtual86 modes either. The patch allows Virtual86 programs to run on a Long Mode kernel just as fast as they do on i486 or i686 PAE kernels. -- Bryan J. Smith Professional, Technical Annoyance [EMAIL PROTECTED]http://thebs413.blogspot.com -- Fission Power: An Inconvenient Solution - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 64-bit compile? - SOLVED
On Wed, 14 Nov 2007 10:16:29 -0800 (PST) Bryan J. Smith [EMAIL PROTECTED] wrote: Hence why I wrote a brief blog article here: 'What is x86-64? Long Mode memory model ...' http://thebs413.blogspot.com/2005/10/what-is-x86-64-long-mode-memory-model.html Thanks for that write-up. It's a truly fascinating read and I can now say that I know a great deal more about the basics of what's going on here than I knew a few minutes ago. In a nutshell, 48-bit (PAE 52-bit) addressed Long Mode is focused on being 32-bit (PAE 36-bit) i486 TLB (i686 PAE) compatible. But there is no reason why it can't support i386 Virtual86 modes either. The patch allows Virtual86 programs to run on a Long Mode kernel just as fast as they do on i486 or i686 PAE kernels. Is there any disadvantage to this patch? Is there any reason why it should not or can't be included in the mainstream kernel? It sounds to me very much like a winning idea -- so why don't we see it built-in by default? I'm thinking there mus t be a downside that I'm not aware of -- MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 64-bit compile? - SOLVED
Frank Cox [EMAIL PROTECTED] wrote: Thanks for that write-up. It's a truly fascinating read and I can now say that I know a great deal more about the basics of what's going on here than I knew a few minutes ago. A lot of people are confused on what x86-64 is. Programmatically, it's just another memory model. At the platform and processor itself, it's far more complex and various between AMD and Intel. E.g., Intel does not and cannot implement an I/O MMU in their aging bus architecture, long story. The I/O MMU is also a great source of errata at the same time. ;) Is there any disadvantage to this patch? If it works as designed, no, it should be a great advantage. Is there any reason why it should not or can't be included in the mainstream kernel? Once it's no longer experimental and is actually trusted, no, it should go into the kernel. It sounds to me very much like a winning idea -- so why don't we see it built-in by default? It's currently experimental. I'm thinking there must be a downside that I'm not aware of Not really. Virtual86 is designed for Protected386. Anything that works under Protected386 should work in x86-64 Long Mode. -- Bryan J. Smith Professional, Technical Annoyance [EMAIL PROTECTED]http://thebs413.blogspot.com -- Fission Power: An Inconvenient Solution - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 64-bit compile? - SOLVED
On Thu, 15 Nov 2007 11:39:59 +1300 Bart Oldeman [EMAIL PROTECTED] wrote: The question is how important the speed is, as most 16-bit programs were written at a time when CPUs were natively slower than the emulation speed now! For me it's not a particularly big deal on my computer; all I do with DOSEMU is write and maintain my PB programs and occasionally run WP/DOS or the like. However, I have a customer who runs a commercial publishing operation that's entirely based around Linux, Scribus, and my PB/DOS programs. I'm rather glad that I didn't set up the x86_64 version of Centos 5 when I put his new application server together a month or so back. At the time I didn't want to do that due to the adventure factor on his production machines. Now I'm taking that adventure on my own computer here and quite enjoying it, but have learned that DOSEMU stuff currently ain't where it's at when it comes to x86_64. Therefore I did the right thing at the time and didn't realize it. PowerBasic runs amazingly well under DOSEMU and because of that I brute force a lot of things that could probably be done a lot more efficiently, but since the action happens pretty much instantly anyway, it's more than good enough anyway. If you or anyone else is interested in my adventures with PowerBasic and DOSEMU, I have an article about it here: http://www.melvilletheatre.com/articles/powerbasic-linux/index.html That article gets a lot of hits every day from people doing Google searches for powerbasic linux and the like. I shall add a bit to it regarding DOSEMU and x86_64 one of these days, now that I've had the opportunity to experiment. -- MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com - To unsubscribe from this list: send the line unsubscribe linux-msdos in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 64-bit compile? - SOLVED
On Mon, 12 Nov 2007 16:39:15 -0600
Frank Cox [EMAIL PROTECTED] wrote:
Having just set this computer up with Fedora 8 x86_64, I am trying to compile
dosemu to run on it. Note that this is (for now) a pure x86_64 system --
there are no i386 libraries installed on it at all.
I got this figured out.
After doing the rpmbuild --rebuild dosemu-1.4.0-1.src.rpm step that errored
out as described in my previous message, I had a file named dosemu-1.4.0.tgz in
my ~/rpmbuild/SOURCES directory. I un-tarred that and after poking around a
bit I found a file named compiletime-settings. I changed the line in that file
that said libdir ${prefix}/lib to libdir ${prefix}/lib64
I then recreated dosemu-1.4.0.tgz in the ~/rpmbuild/SOURCES directory so it now
contained the modified compiletime-settings file. After that, doing a rpm
-bb ~/rpmbuild/SPECS/dosemu.spec created the file that I wanted,
dosemu-1.4.0-1.x86_64.rpm. I installed it and it appears to work as expected.
PERFORMANCE
This 64-bit DOSEMU compile runs substantially slower than the 32-bit compile
that I used previously on this computer. I have several rather large
PowerBASIC/DOS programs that are, in fact, the main reason why I use DOSEMU.
Up until a couple of days ago, I had Fedora 7/i386 on this computer. I just
happen to still have the numbers when compiling one of those programs with
PowerBASIC/DOS under DOSEMU:
With F7/i386: 1686600 lines per minute -- total time to compile the program:
0.2 seconds
With F8/x86_64: 230400 lines per minute -- total time to compile the program:
1.6 seconds.
The F8/x86_64 DOSEMU is running approximately 13 times slower.
I understand that DOSEMU has to do more work to run on a x86_64 architecture.
However, I'm wondering if there is something that I missed or something that I
should do (compiler options?) that would give it a bit more oomph.
--
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
