OSDev.org

Do people whisper behind your back, "He's not computing with all 64 bits... poor fellow"?

-Thomas F. Devine


I am about to take the plunge, dig myself into another hole of debt and get an AMD Athlon 64 machine. I think I will start my kernel off as a native 64-bit kernel, rather than a 64-bit hack on top of a 32-bit kernel.

Would anyone like to start a FAQ on this topic, and write about it in the Wiki FAQ? I'll be starting on it when I get the machine and have something up and running. In the mean time please PM me or register your interest here.

I'd like to get a discussion going. Anyone like to kick it off? First up, with assembly language... maybe we'll need to patch up NASM so we can use [BITS 64] and so on... I wonder if registers in the Athlon x86-64 are EEAX, etc?

By the way, Intel have done a backflip on 64-bit x86 and are now committed to cloning the Athlon 64! ;D

I too would be interested in info on this out of curiosity. I also think an addition to the Wiki FAQ would be nice too, but I'll just stop talking because I'm of no help .

Candy did some preliminary work in the GCC Cross-Compiler page; that means a functional GNU 'as' is available. (Must... resist... gas... advertising... )

If there are any specialities to working with that architecture, add either the speciality to the relevant Wiki page, or a link to a dedicated subpage. I belive that's better than spawning a complete "64bit FAQ", because in the end that would lead to a PowerPC FAQ, a MIPS FAQ, an ARM FAQ etc. etc. be spawned, too, and everybody getting confused.

IMHO, of course.

kernel_journeyman wrote: I am about to take the plunge, dig myself into another hole of debt and get an AMD Athlon 64 machine. I think I will start my kernel off as a native 64-bit kernel, rather than a 64-bit hack on top of a 32-bit kernel.

That's a nice idea. Did you read up on the 32-bit compatibilities in AMD64?

Would anyone like to start a FAQ on this topic, and write about it in the Wiki FAQ? I'll be starting on it when I get the machine and have something up and running. In the mean time please PM me or register your interest here.

The idea about a FAQ is that there are people asking questions. There are barely any people asking questions about AMD64. Still, I must say I'm very much interested in giving you a testing module of my kernel in about 2 - 4 months, it should be doing 64-bits then.

I'd like to get a discussion going. Anyone like to kick it off? First up, with assembly language... maybe we'll need to patch up NASM so we can use [BITS 64] and so on... I wonder if registers in the Athlon x86-64 are EEAX, etc?

Oh dear oh dear oh dear....

we seem to have a problem . At least, according to _ALL_ AMD64 sources, since about the end of 2002, the registers were rax...rsi plus r8...r15. Also, you got rflags & lots of MSRs.

Do you have the manuals AMD spreads?

By the way, Intel have done a backflip on 64-bit x86 and are now committed to cloning the Athlon 64! ;D

You know the problem about cloning, they don't live as long and they have hideous deformities.

Intels iAMD64's don't do syscall in 64-bit mode without indicating that in the flags (there's no flag for that particular combination, and they do some form of 64-bit, and they do support syscall in 32-bit mode), plus they've left out numerous best functions, and they've added sysenter/exit to 64-bit mode which was left out explicitly. Also, what is probably obvious, the MSR's are completely different.

Anyway, nice to hear there is somebody else who's going to buy a 64-bit machine just for osdev (it's not listed on dell's categories! it's not fair! 8D). I am still thinking of saving up until I've got enough for a dual machine, and I've finished my NUMA MP starter... Although that doesn't help in getting smp support, it does help for the future.

Candy did some preliminary work in the GCC Cross-Compiler page; that means a functional GNU 'as' is available. (Must... resist... gas... advertising... )

Yes, it's true there is a GAS that can assemble for AMD64, that is, as far as it can assemble. There is also a GCC that generates more or less terrible code, because amd64 is a quickhack on 32-bit for them. Expect to see code moving things from the amd64 spots to the 32-bit spots, back to registers, do something, back to 32-bit, back to 64-bit, returning, jumping around a lot, etc... :S

If you want a different syntax-assembler, try YASM, which I've heard also supports AMD64. Also, on masmforum.com there's a nasm64developer user, who eh... indicates he's a developer for nasm's 64-bit support. You could contact him for testbuilds or help (as in, helping him, not the other way around).

Candy wrote: Intels iAMD64's don't do syscall in 64-bit mode without indicating that in the flags (there's no flag for that particular combination, and they do some form of 64-bit, and they do support syscall in 32-bit mode), plus they've left out numerous best functions, and they've added sysenter/exit to 64-bit mode which was left out explicitly. Also, what is probably obvious, the MSR's are completely different.

Also their's no NX bit AFAIK. This is all probably Intels ideas of tying to ruin AMD64 so no one uses it, yet another anti competative practice. But if everyone's Intel version doesn't work but they already see the AMD one working, it could back fire for them.

Anyway, nice to hear there is somebody else who's going to buy a 64-bit machine just for osdev (it's not listed on dell's categories! it's not fair! 8D).

I will have a go when I get one (I may treat it as a different, although compatible, platform than i386).

Dell are just a load of Intel loving g*ts.

Yes, it's true there is a GAS that can assemble for AMD64, that is, as far as it can assemble. There is also a GCC that generates more or less terrible code, because amd64 is a quickhack on 32-bit for them. Expect to see code moving things from the amd64 spots to the 32-bit spots, back to registers, do something, back to 32-bit, back to 64-bit, returning, jumping around a lot, etc...

That's terrible!! Will they improve it, or can't they be bothered? Will be need to start finding a new compiler?

srg

srg wrote: That's terrible!!

...but not unexpected in a new architecture, especially when the guys writing the code generator have yet to learn many things.

Such "register ping-pong" isn't unheard of, and might not even affect the "felt" performance as much as you might think. Other things have much more impact on your OS performance. Even AmigaOS, fabled for its efficiency, had it's fair share of register ping-pong:

I once followed a call to an Intuition routine; this is what was happening: C calculates the parameters (in registers), stuffs them onto the stack, calls the stub routine. Stub routine puts them into the registers, calls Intuition. In the ROM, the parameters are put back onto the stack, and the actual routine is called... which reads some of the stack parameters back into registers. - Fun!
-- David Gay, comp.sys.amiga

Will they improve it, or can't they be bothered?

AMD64 is hardly a "niche" architecture, and so future improvements are very likely.

Will we need to start finding a new compiler?

I seriously doubt you will find a free (as in free beer) compiler for the AMD64 that will outperform GCC in the long run. Last time I looked (which has been some time, granted) GCC was even the official AMD64 compiler, wasn't it?

Just go ahead and write your C code. Then, when a better GCC is released, just recompile and get your instant voila.

srg wrote: Also their's no NX bit AFAIK. This is all probably Intels ideas of tying to ruin AMD64 so no one uses it, yet another anti competative practice. But if everyone's Intel version doesn't work but they already see the AMD one working, it could back fire for them.

To quote intel on the NX bit, "it's only important for high-end machines". They don't even have a clue what it is...

The main point behind architectural improvements is that the user DOESN'T see it. He just feels it because of more programs (easier programming/debugging), less crashes (more stable, no stack overflows) etc. The only thing that the user MIGHT notice is that the OS does work on AMD's and not as reliably on intels, and explain it that it was specially developed for amds (which it isn't), it was made not to work on intels (not by me! by intel!) or it was a really bad product anyway (and that it isn't).

I will have a go when I get one (I may treat it as a different, although compatible, platform than i386).

Dell are just a load of Intel loving g*ts.

Inno... still, I'm looking for an MP opteron, to test NUMA activating... :-\ they're expensive as hell!

NoeXecute bit ... warf. i'm just laughing internally while i read that "How MS and AMD together can prevent viruses ..." You can have *exactly* the same protection effect by a proper use of segments in IA32 (and iirc there's a Linux patch that does so) ...

Though as the 64bits no longer use the 'segment' abstraction, they had to put the 'not executable' property somewhere else ... and they put it in pages, just as SPARCs, PowerPCs and other processor do.

Pype.Clicker wrote: NoeXecute bit ... warf. i'm just laughing internally while i read that "How MS and AMD together can prevent viruses ..." You can have *exactly* the same protection effect by a proper use of segments in IA32 (and iirc there's a Linux patch that does so) ...

Yes, but. The idea behind flat-mode is that you do not screw around with segments. The idea behind 32-bit no-execute is that you screw around with segments. Not quite the same idea, now is it... Still, I'm picking up the segmented noexecute, and am going to implement it . Thx for the idea .

The "prevent viruses"-idea is just pure laugability. There's no way that's going to help them prevent viruses. It prevents one (1) method of accessing the system, through non-approved means. The point of this is, there are other ways (numerous) how it can enter the system, and most users are stupid enough to approve them anyway, so then all hope is gone.

Though as the 64bits no longer use the 'segment' abstraction, they had to put the 'not executable' property somewhere else ... and they put it in pages, just as SPARCs, PowerPCs and other processor do.

So true. Still, I feel it's better off there for all flat-mode OSes.

actually, you can keep the 'flat model' (i.e. the user program do not mess with segments) but still restricting the size of the code segment (the user has no right to fill an array with bytes and decide it is code: the size of the code segment is under strict control of the OS). All it require is that your process has its own code segment, with its own code size limit ...

As your user program *doesn't* know about the code segment of other processes, it can hardly tell it's protected.

hmm ... just one thing... is the 32/64 bits a "per address space" thing or a global thing. i mean can we easily mix existing 32 bits programs and new 64 bits ones on the same OS ?

Pype.Clicker wrote: hmm ... just one thing... is the 32/64 bits a "per address space" thing or a global thing. i mean can we easily mix existing 32 bits programs and new 64 bits ones on the same OS ?

per address space. You run in long mode (for 64-bit OS, always), and within long mode you can make a 64-bit code segment or a compatibility mode code segment, and the second is plain 100% compatible with 32-bit code. Theoretical binary compatibility even, you don't have to recompile 32-bit apps to work on the 64-bit OS. If your OS screws that up, it's not your fault

and i guess there are no segmentation performed even in 'compatibility' mode ... only in 'protected mode' (eg. 16->32, not 16->32->64>32)

a placeholder for answers...
http://www.osdev.org/osfaq2/index.php/T ... s%20CPU%20...

Do you not think, you may be better off waiting a bit, Before making a 64 bit OS, These are Y i think you should wait a bit .
1) There is just, Not enough info on programming them yet :'( .
2) They will be more likely to be open to viruse's (By this i mean that the viruse's writer's are more likely to find loop holes in a new processor :'( .
3) They will be slower than 32 bit in some application's :'( .
4) There will be alot of people that get 64bit process and then not be able to get programs or have problem with them and be put off :'( .

I would say wait 2 year and then go for it .

ASHLEY4.