OSDev.org

Posted: **Mon Nov 28, 2005 8:21 am**

<splitted> as seen in faster API calls</splitted>

Brendan,

no I thought of a general 64bit-mode-only discussion threads, to ease the job of separating 32bit know-how burden from 64bit wheat by eliminating it...

Was just a proposal, but it seems that apparently not too many go for 64bit-mode-only-OSses at the moment.

Thanks for your opinion to use SYSCALL/SYSRET, at about 60 cycles as far as I remember, probably no faster solution possible...

Cheers, tigujo

Posted: **Mon Nov 28, 2005 4:44 pm**

To Candy,

thanks, you seem to have pleased my mind, as cool British would say, but I'm not.

I still want to know, if there is room on this forum to start a separate section on 64bit mode. By far, I do not have the impression, that this mode is of fundamental importance.

But it is of some importance to x86 and the way business goes.

Seeing that AMD could win with inspiration at least for a moment over sheer market power (INTEL) I'd like to see followers in our community wrenching down the iron curtains, those in all of our minds, and take this tiny bit of improvement (not only because of sixtyfour bits) as a chance to break free from 'brain-damaged-architectures', as one of the founders of Glockenspiel C++ of Ireland used to paraphrase the notorious Intel achievements.

BTW, this company - Glockenspiel - has lost, IMHO because to be too sprite too early...

They had in their include files the famous define #ifdef BDA - aka 'brain damaged architecture' - as a synonym for Intel or x86. Well...

So, why not start a thread with a still realistic view and strong foundation on cumbersome x86but64, and add - being even carried away by visions - the peronal wishlists how things could be done?

Getting into x86 at a stage, even when x86-64 is here, makes me wonder. Actually, half of my time I do spend on designing new processor architectures, not because I know how to do it, but because I need some reluctance from what I see. Understnad it, or forgive it. Both welcome.

Pragmatic:
If no one - meaning: not too many ones - take some of the promises of x86-64 serious, I said promises, not actual implementations, then we will end up in migrating the cumbersome to something for sure less cumbersome, but that's all. Next generation programmers will just learn, that finally there is just some additional mode here.

I want to advocate for a clear cut. Not to abandon what was, but to make ground for a new phase.

Let's start OS64 as a top level section.

If you look on OpenGL, you will find, that there is a generation change on the way, or at least under the hoods.

Sorry, for being emotional, but I guess you know, tough programming does need emotions indeed.

Otherwise you couldn't stand that crap

Cheers, tigujo

Posted: **Mon Nov 28, 2005 7:38 pm**

Hi,

tigujo wrote:I still want to know, if there is room on this forum to start a separate section on 64bit mode. By far, I do not have the impression, that this mode is of fundamental importance.

The idea of a seperate section for 64 bit mode does have some merit, as some discussions apply to 64 bit only. However, some discussions apply to messaging OSs only, some apply to paging systems only, some apply to monolithic kernels only, some apply to specific device drivers only, etc. If a seperate section was created for 64 bit, then you'd want to create seperate sections for everything else too and you'd end up with lots of seperate sections with 3 discussions in each.

A simpler idea would be for people to use the "Subject" line of new discussions to indicate the subject, so that everyone can see easily what that particular discussion is about...

tigujo wrote:Seeing that AMD could win with inspiration at least for a moment over sheer market power (INTEL) I'd like to see followers in our community wrenching down the iron curtains, those in all of our minds, and take this tiny bit of improvement (not only because of sixtyfour bits) as a chance to break free from 'brain-damaged-architectures', as one of the founders of Glockenspiel C++ of Ireland used to paraphrase the notorious Intel achievements.

AFAIK Intel wanted to dump 80x86 and move to a clean Itanium architecture (without any "backward compatability"). AMD's long mode is a continuation of (or addition to) the 'brain-damaged-architecture'. For 64 bit you've still got things like that A20 gate, PIC chips, RTC, ISA DMA controller, several different ways of handling hard drives, the mess that is memory detection, etc. The only thing that changes is the CPU, and that has become more ugly rather than less - try using an "or rax,0x1234567890ABCDEF" instruction to see just how clean it is.

Cheers,

Brendan

Posted: **Mon Nov 28, 2005 9:20 pm**

if the chip manufactures were to redsign the whole architecture from scrap. It would be even harder for people like us to make an os. already there is to many diverent device architectures comming out each day. It's why windows is so "popular". the manufactures make the drivers for microsoft.

Posted: **Tue Nov 29, 2005 3:14 am**

Brendan,

Could you elaborate on your 64-bit sample instruction you posted above? I haven't moved to 64-bit programming yet and am interested in its pitfalls.

I also thought that Intel was moving away from Itanium to embrace 64-bit mode the way AMD has. Am I totally wrong on that? I seem to remember reading about that somewhere.

If I / we / whomever develops for longmode 64-bit, will it work on 64-bit non Itanium Intel processors as well?

Posted: **Tue Nov 29, 2005 3:58 am**

tigujo wrote: thanks, you seem to have pleased my mind, as cool British would say, but I'm not.

I still want to know, if there is room on this forum to start a separate section on 64bit mode. By far, I do not have the impression, that this mode is of fundamental importance.

The mode isn't of fundamental importance, which is the reason it's not a separate forum. Nothing in OSDev is so required or binary that you can actually separate a forum for it and expect even distribution. You'd have to split off every segment of OSDev to make that somehow workable, and if you do that you get a number of subfora which nobody ever visits, because it's too damn low in traffic.

However, you can specify which segment you're targeting. So, if you're targeting 32-bit computers that imo will go to the dumpster in 5 years, please do say so and I'll refrain from mentioning AMD64 things that could make your life a whole lot easier.

Seeing that AMD could win with inspiration at least for a moment over sheer market power (INTEL) I'd like to see followers in our community wrenching down the iron curtains, those in all of our minds, and take this tiny bit of improvement (not only because of sixtyfour bits) as a chance to break free from 'brain-damaged-architectures', as one of the founders of Glockenspiel C++ of Ireland used to paraphrase the notorious Intel achievements.

BTW, this company - Glockenspiel - has lost, IMHO because to be too sprite too early... They had in their include files the famous define #ifdef BDA - aka 'brain damaged architecture' - as a synonym for Intel or x86. Well...

So, why not start a thread with a still realistic view and strong foundation on cumbersome x86but64, and add - being even carried away by visions - the peronal wishlists how things could be done?

Getting into x86 at a stage, even when x86-64 is here, makes me wonder. Actually, half of my time I do spend on designing new processor architectures, not because I know how to do it, but because I need some reluctance from what I see. Understnad it, or forgive it. Both welcome.

You appear to not know that new Intels also use 64-bit technology which is 99% compatible with AMD's, and that neither is mass-producing chips without it.

Pragmatic:
If no one - meaning: not too many ones - take some of the promises of x86-64 serious, I said promises, not actual implementations, then we will end up in migrating the cumbersome to something for sure less cumbersome, but that's all. Next generation programmers will just learn, that finally there is just some additional mode here.

I sure hope to change the "additional mode" view, in the same way that people nowadays consider realmode to be a nonexistant thing and that it's only good for reaching protected mode. Protected mode isn't just "another mode", it's atm the only serious mode for a new x86 OS. Any other one is seriously limited. The cause for AMD64/EM64T are the limits of protected mode, and its effect of making most quick techniques impossible due to old inheritance. It's been designed to allow those quick techniques (such as the one in discussion here) to work without requiring weird structures (task gate for page fault...) for it to work reliably.

What did GRUB stand for? It wasn't advocating realmode writing for new OS developers, it was for ridding the world of all realmode attempts.

I want to advocate for a clear cut. Not to abandon what was, but to make ground for a new phase.

Let's start OS64 as a top level section.

No. Same reason we don't have a separate SPARC development board, or a MIPS R3000 development board, or any other specific board (not even x86!). It doesn't work since most questions aren't about specifics, and if they are most answers will help you understand it. All systems were based on concepts, and if you understand the concepts, you can figure out the specifics.

Posted: **Tue Nov 29, 2005 4:28 am**

Hi,

Rob wrote:Could you elaborate on your 64-bit sample instruction you posted above? I haven't moved to 64-bit programming yet and am interested in its pitfalls.

The "or rax,0x1234567890ABCDEF" instruction? The story is that 64 bit instructions can't have 64 bit immediate data, and there's no way to encode this instruction. Instead you'd need to do something like:

Code: Select all

somewhere:
   dq 0x1234567890ABCDEF

   or rax,[somewhere]

The only instruction that can have a 64 bit immediate value is "mov", so alternatively you could do:

Code: Select all

somewhere:
   mov rbx,0x1234567890ABCDEF
   or rax,rbx

For 64 bit mode, the instruction set is still mostly 32 bit, linear addresses are 48 bit, physical addresses are 48 or 36 bit. The only thing that actually is 64 bit are the general registers (and MMX registers, but they've been 64 bit for a decade now).

Rob wrote:I also thought that Intel was moving away from Itanium to embrace 64-bit mode the way AMD has. Am I totally wrong on that? I seem to remember reading about that somewhere.

I can't tell - too hard to find the truth buried under all the marketting material...

Rob wrote:If I / we / whomever develops for longmode 64-bit, will it work on 64-bit non Itanium Intel processors as well?

Yes - it's all the same (with minor differences between manufacturers, and between CPU models from the same manufacturer)....

Cheers,

Brendan

Posted: **Tue Nov 29, 2005 4:28 am**

tigujo wrote: Let's start OS64 as a top level section.

If you mean something like the 'general programming forum', i would be rather against it because of visibility. I mean, i'm able to track one board of the forum but rarely go back to other boards. I'm not doing 64-bit OSdev, but still i'm interrested on what's going on there ...

There are, however several ways for you to make clear you're working on 64-bit longmode framework: your signature, your avatar, your threads' titles, etc.

If people see "Gimme long 64 mode", i guess they can be safely assuming you're not interrested in comments regarding 32-bit multisegments design ^_^

Posted: **Tue Nov 29, 2005 5:30 am**

I'm happy with all the comments so far, the idea of having a subject line with something like "OS64" to indicate relevance to x86-64 mode only, seems to work best for this forum.

Thanks for all the replies,
cheers, tigujo

ps: I'm curious, how many people work on a OS64 at the moment...

Posted: **Tue Nov 29, 2005 7:55 am**

Hi,

tigujo wrote:ps: I'm curious, how many people work on a OS64 at the moment...

My OS is for 32 bit, 36 bit (PAE) and 64 bit with 3 different kernels (built out of modules so that most of the 32 bit modules can be used for both 32 bit and 36 bit kernels). I haven't got much done on the new version yet though - I've been spending time writing a BIOS instead.

Candy is "64 bit only", as mentioned earlier. Not sure which other forum regulars are working with long mode...

Cheers,

Brendan

Posted: **Tue Nov 29, 2005 8:07 am**

Brendan wrote: My OS is for 32 bit, 36 bit (PAE) and 64 bit with 3 different kernels (built out of modules so that most of the 32 bit modules can be used for both 32 bit and 36 bit kernels). I haven't got much done on the new version yet though - I've been spending time writing a BIOS instead.

Writing a BIOS? Why that?

Candy is "64 bit only", as mentioned earlier. Not sure which other forum regulars are working with long mode...

Aiming for, rather. I've only recently started porting my OS from 32/36 bit to 64 bit. I'm starting to clean out some of the 32-bit only things since it messed up the code, and I don't see any real advantage. I'm kind of doubting the choice of moment, since I don't have any physical 64-bit computer to test on atm.

Posted: **Wed Nov 30, 2005 2:46 am**

candy wrote

Aiming for, rather. I've only recently started porting my OS from 32/36 bit to 64 bit. I'm starting to clean out some of the 32-bit only things since it messed up the code, and I don't see any real advantage. I'm kind of doubting the choice of moment, since I don't have any physical 64-bit computer to test on atm.

Guess the advantage is not really there for the OS developers, but more for the application developper. In general more registers means less memory reference and thus improving speed.

brandan wrote

The "or rax,0x1234567890ABCDEF" instruction? The story is that 64 bit instructions can't have 64 bit immediate data, and there's no way to encode this instruction. Instead you'd need to do something like:

Code:
somewhere:
dq 0x1234567890ABCDEF

or rax,[somewhere]

This is rather nice. seen it on mips a lot and is very usable for compilers. They can reuse the somewhere location to reduce codesize (if you don't modify it).

Posted: **Wed Nov 30, 2005 3:46 am**

RetainSoft wrote:
Aiming for, rather. I've only recently started porting my OS from 32/36 bit to 64 bit. I'm starting to clean out some of the 32-bit only things since it messed up the code, and I don't see any real advantage. I'm kind of doubting the choice of moment, since I don't have any physical 64-bit computer to test on atm.
Guess the advantage is not really there for the OS developers, but more for the application developper. In general more registers means less memory reference and thus improving speed.

Well... I can see lots of things that I can abuse:

- One type of paging
- Always USB support in some form
- No PS2 support
- No floppy support
- No parallel support
- No serial port support
- Always ATA-6+ harddisks and controllers
- Same memory controllers
- Always remappable through NUMA
- No address space shortage
- More registers (yes, finally, it's in the list)
- No old bugs from some obscure chipset that can still come and bite me (CMD640 chipset? ever heard about it?)
- Less code means less bugs
- Less configuration options means less interaction, means less interactional bugs
- Tweaked to allow fast speedways (such as the single stack for user/kernelmode for a task) which are intuitive, but not reasonably possible on plain x86
- Even lots more.

I must say, not supporting it does allow a whole lot of options for me.

Downsides are of course, less computers and bleeding-edge stuff.

My only downside point is that I might not have a test computer. However, I've received a new work computer yesterday and it's a 2.8ghz xeon with HT, so it might just... *hoping*...

Posted: **Wed Nov 30, 2005 6:14 am**

Hi,

Candy wrote:Writing a BIOS? Why that?

Bochs!

There's a pile of small reasons for it, but mainly I want a single BIOS image that works regardless of how the emulator itself is configured (rather than the 10 different BIOS images I have now), plus a whole pile of extra options (like dynamically setting up an ACPI SRAT table so I can use Bochs to emulate NUMA machines).

Candy wrote: - Always USB support in some form
- No PS2 support
- No floppy support
- No parallel support
- No serial port support
- Always ATA-6+ harddisks and controllers
- Same memory controllers
- Always remappable through NUMA

You're not supporting 64 bit Intel chips??? My 64 bit computer is ET64 (without an "AMD style" memory controller), it's using the PS/2 keyboard and mouse because of the keyboard/video/mouse switch, there's a 56 Kbps fax modem in the serial port (mainly for sending faxes) and a colour Epson bubblejet on it's parallel port. One of the hard drives is a 4 GB drive I use for backup/archive purposes that I bought when the computer was a 100 Mhz Pentium (probably not ATA 6). It also has a floppy drive, which I use fairly regularly.

This is one of the things I like about my own plans - device drivers running at CPL=3 as normal processes, combined with a 64 bit micro-kernel that will eventually run 32 bit processes...

Cheers,

Brendan

Posted: **Wed Nov 30, 2005 7:06 am**

Brendan wrote: You're not supporting 64 bit Intel chips??? My 64 bit computer is ET64 (without an "AMD style" memory controller), it's using the PS/2 keyboard and mouse because of the keyboard/video/mouse switch, there's a 56 Kbps fax modem in the serial port (mainly for sending faxes) and a colour Epson bubblejet on it's parallel port. One of the hard drives is a 4 GB drive I use for backup/archive purposes that I bought when the computer was a 100 Mhz Pentium (probably not ATA 6). It also has a floppy drive, which I use fairly regularly.

Hm... I'm still aiming for computers in about 4 years, which probably won't look like these ones. The EM64T (not ET64 btw) memory controller could make that plan go up in smoke, but remapping NUMA-style should only prove to be required as soon as people use 32-bit PCI devices and 4GB of memory or more, which should be in about 2-3 years for the common computer. I'm aiming for newly-sold-computer-compatibility, so that everybody with a new computer can run it. If I support all old software, it gives me a load of overhead I can't cope with and I'd be lagging behind at all times. I estimate that this configuration will be the common cut in 4 years, so I develop for it.

If you look at the computer configuration now, which components will you probably be using in 4 years time?

I think you'd probably keep the kvm switch if it cost you a lot of money (and it probably did) or has a lot of features (in which case #1 also applies). The printer won't survive another four years, the harddisk will become irrelevant in a few years (flash disks / tape / dvdr becoming excessively cheap or some other method replacing it, or it just grinds to a halt), the fax could still form a thing that requires support although an AC97 fax device would suffice too, and the memory controller is something Intel should come back to in some time. At least, I expect.

Back porting requirement for your computer in 4 years: one PS2 controller and possibly one serial driver. If that means that I can spend the time getting it to run properly with your video card or your network card, that'll be more useful by then.

That cuts down my driver list to only a few drivers (I'm trying to support one of each type of device, possibly two or three), and if I should prove to be wrong about one or more of the details (I'm expecting people to shout about the parallel port for the next year, floppy disk for about half a year, ps2 for at least 2-4 years so I might implement that in any case, scsi support by people who happen to have scsi devices until scsi dies out or until I come around to implementing the drivers, etc.) I can come back and fix it. I want the OS to be oriented around the 2010 computer, so that it runs at top-speed for those. If that means emulating the 2003 computer or requiring hacks for the 1997 computer, I don't care.

<break, again...>

OSDev.org

clear-cut 64 bits architecture ? (splitted)

clear-cut 64 bits architecture ? (splitted)

Re:Fastest possible kernel API call?

Re:Fastest possible kernel API call?

Re:Fastest possible kernel API call?

Re:Fastest possible kernel API call?

Re:Fastest possible kernel API call?

Re:Fastest possible kernel API call?

Re:Fastest possible kernel API call?

Re:clear-cut 64 bits architecture ? (splitted)

Re:clear-cut 64 bits architecture ? (splitted)

Re:clear-cut 64 bits architecture ? (splitted)

Re:clear-cut 64 bits architecture ? (splitted)

Re:clear-cut 64 bits architecture ? (splitted)

Re:clear-cut 64 bits architecture ? (splitted)

Re:clear-cut 64 bits architecture ? (splitted)