I've decided that it is a good time to announce that I have been working on the 64-bit version of DynatOS, which will run on AMD64 and Intel 64 computers.

I've released what I would call an aesthetically equivalent of the 32-bit version (although much more functional internally) for people to play with while I continue my work on DynatOS. The download file, containing instructions, can be found at the DynatOS Downloads Page.

The current download has been tested in Bochs, on an AMD64 3400+, on an AMD64 3000+ and on an AMD Turion64 x2 notebook.

Below is a summary of what has been done so far, what needs to be done and what might be in the future for DynatOS.

Current Summary

  • Used the 32-bit DynatOS source code as the base

  • Memory Address Space is now a 256TB single address space

  • Process Address Space is 2GB by default and co-exists with others in the global 256TB address space, which will help minimize cache/TLB misses and other performance issues

  • Implemented Long Mode Initialization; Real Mode and Protected Mode are for solid bootstrapping only

  • 64-bit Interrupts

  • Application Binary Interface calls through the INT 0x30 interface have been deprecated in favor of utilizing the SYSCALL instruction/interface

  • Full 64-bit Memory Manager with accompanying INT 0x0E Page Fault (#PF) handler in which supports on-demand memory usage for maximum efficiency

  • RAM is now accounted for via the RAM Stack as opposed to the 32-bit version's Bitmap implementation

  • Full 64-bit Process Manager with Low, Normal, High and Real Time process priority switching

  • Ring-3 protection for standard applications

  • Basic read-only standard Floppy Disk Driver



Foreseeable Todo List

  • Finish the Resource Manager

  • Finish the Drive and Storage Manager

  • Finish the native filesystem driver

  • Revamp the Floppy Disk Driver to support writing

  • Solidify the relationship between Device Drivers, Filesystem Drivers, the Resource Manager and the Drive and Storage Manager

  • Design a standard, useful and meaningful set of functions for the Application Binary Interface

  • Design a more thoughtful and useful Command Line Interface

  • Modify the Process Manager to allow thread priorities and switching

  • PCI Configuration and dynamic driver loading

  • ACPI

  • APIC

  • Standard/Generic IDE Hard Disk Driver

  • NUMA Domains

  • Multi-core/processor support

  • Utilize the "Interrupt Stack Table" concept to guarantee the success of critical interrupts/exceptions

  • Graphical User Interface and accompanying API



Possible Interests

  • Compatibility Mode Application Support

  • Hypervisor capabilities via native SVM architecture



Any questions or comments??? Please let me know!!!

Enjoy :)
Posted on 2007-10-21 22:23:39 by SpooK
Just a silly clarification (I'm ashamed telling this actually :oops:), Intel 64 shouldn't be Intel EM64T? Although as an assembly programmed OS would be hard to support Itanium and AMD64 architectures, I think you should use the specific term to be sure that you will not misguide the "quick readers".

End of my silly post :P
Posted on 2007-10-22 00:19:45 by LocoDelAssembly

Just a silly clarification (I'm ashamed telling this actually :oops:), Intel 64 shouldn't be Intel EM64T? Although as an assembly programmed OS would be hard to support Itanium and AMD64 architectures, I think you should use the specific term to be sure that you will not misguide the "quick readers".

End of my silly post :P


That is what I kept for the longest time, but they have changed the name from Yamhill, to Clackamas Technology (CT), to IA-32e, to EM64T... and finally the latest name being Intel 64.

I could see how people can confuse Intel 64 with IA-64, but as long as they continue to call it that... so will I :)
Posted on 2007-10-22 08:18:32 by SpooK
How many Itanium developers are there? Ed, Ronald, and Donald. Eh, maybe I forgot one. Just send them an email and be done with it, lol.
Posted on 2007-10-22 09:20:11 by bitRAKE
bitRAKE,

Believe it or not, more and more people are making the switch to x87 (x86-64) specific architectures... makes me feel like an outdated fossil. :(  <cough>damn</cough> <cough>you</cough> <cough>keith</cough> :p

I'll probably look over DynatOS/64 but I've said it once, I'll say it a thousand times if need be; I learned 8 bit, 16 bit, and 32 bit.. I don't have it in me to go through the trouble of learning the ins and outs of another one. I'll probably start using C again (or more than likely, give up programming all together) when 32 bit systems are no longer used.
Posted on 2007-10-23 00:27:20 by Synfire
( Synfire, Itanium is another beast all together http://en.wikipedia.org/wiki/Itanium . I spent a couple hours with the manuals to get an overview of the architecture - it's amusing, but not x86 really. I was attempting to be sarcasticly humorous, but failed. Programming is a process to me - not a language. I linked to wiki again, haha. )
Posted on 2007-10-23 01:36:43 by bitRAKE

bitRAKE,

Believe it or not, more and more people are making the switch to x87 (x86-64) specific architectures... makes me feel like an outdated fossil. :(  <cough>damn</cough> <cough>you</cough> <cough>keith</cough> :p



Not sure about the name x87 as that is the designation for the FPU.


I'll probably look over DynatOS/64 but I've said it once, I'll say it a thousand times if need be; I learned 8 bit, 16 bit, and 32 bit.. I don't have it in me to go through the trouble of learning the ins and outs of another one. I'll probably start using C again (or more than likely, give up programming all together) when 32 bit systems are no longer used.



From an assembly language programming point of view, there is not much to learn. A few opcodes (ascii-adjust, bound, single-byte inc/dec... and others no one will greatly miss) have been removed.

You have 16 64-bit GPR's with the capability to address the lower byte of SP/BP/SI/DI as SPL/BPL/SIL/DIL. However, during extended register operations, you cannot address AH/BH/CH/DH. I have yet to see this as a problem in any context.

A big adjustment is relative addressing, but that is usually not a concern for general applications... let the assembler/compiler/linker do the work.

Most 32-bit code simply works when reassembled as 64-bit. If you want full support, Compatibility Mode as a subset of Long Mode ensures that 32-bit applications will work as they did with the 32-bit series predecessor without having to switch the processor to and from Protected Mode :)

From an operating system development perspective, I just reduced the amount of overall work needed. I don't have to deal with most legacy stuff. I am guaranteed to have PCI, CPUID, RDTSC, SYSCALL and other useful concepts. I have MMX and XMM available, instead of the x87 FPU, if I need it. 64-bit values, such as the system (millisecond) timer, can be handled without ADC or the like.

With DynatOS, specifically, I am going to push the Dynatos Virtual Machine Architecture as the primary method of program development/execution. This is how DynatOS can have multiple processes running inside the flat 256TB address space without worrying about programs trashing each other. I personally look forward to making a final switch to the Dynatos VM Architecture and concentrate mainly on that :D

PS: If you want to learn the Itanium, then that's all on you as I'm not in need a personal space heater :P
Posted on 2007-10-23 13:31:16 by SpooK
Not sure about the name x87 as that is the designation for the FPU.


I guess I'm going to have to correct a few people then, there are quite a few people, including myself, that have been calling the IA-64 line x87 as it's the next logical (major) step in the series, and including FPU into x86. Goes to show how closely I've been following the new hardware. :p

---

Biggest thing I was talking about was optimization. With each processor I had to reread a boatload of manuals and then spend hours screwing around with code to just find out what works best where. I'm just nowhere near as dedicated as I was back in my teen years and I don't see me hacking around in a debugger to learn to get decent preformance out of drivers/applications on these new systems. That being the case, there really wouldn't be much of a difference between programming in C rather than programming in asm. It's not like I'm going to get any size/speed optimizations.
Posted on 2007-10-24 22:22:42 by Synfire

That being the case, there really wouldn't be much of a difference between programming in C rather than programming in asm. It's not like I'm going to get any size/speed optimizations.


Getting tougher to do... but the x86-64 isn't close enough to RISC to dismiss ASM altogether :)
Posted on 2007-10-24 23:15:24 by SpooK
Synfire: another small correction, IA-64 == Itanium not x86-64/EM64T/x64/etc :)
Posted on 2007-10-25 03:57:12 by f0dder
SpooK,

I disagree there mate, I'd never use C on a RISC based device (unless required to for a job)... Something like that would be worth the effort just for the fact that most RISC processors don't really have much to them compared to the CISC processors.

f0dder,

Bleh, what the hell are these guys smoking now-a-days. They need to stay off the meth and pick singular naming convention... So now why isn't x86-64/EM64T/x64/etc included in IA-64? Just because their not explicitly "Intel".. pfft. Screw it, Intel ganked half of the design for their processor from the POWER3 IBM series processor anyways (with the exception of dropping the FPU support, note this is because the POWER3 was released in 1998 a year before SSE was designed so it kept support for FPU for backward compatibility), just threw the 80x86 instruction set on top of it ... I wonder if this has to do with the whole "You can't copyright a version" deal Intel was griping about some time back... I've never been one to be good with terminology to begin with but hell this gives me a headache! lol :p
Posted on 2007-10-27 01:36:42 by Synfire
Synfire: why isn't x64 == IA-64? Simple, IA-64 is intel's Itanium stuff, which is a completely different architecture from x86. Several years after Itanium, AMD decides to hack on 64-bit support to x86 which imho was a bad idea (we finally had a chance to escape the clutchy x86 patchwork with the move to 64bit).

Imho it should have been called x86-64 or x64, but it has sooo many names... AMD64 which is misleading because it's not a completely new thing (x86 instruction) and sounds like it's incompatible with x86 (which it isn't), the various names intel have been using for it, etc.

Everybody plagiarizes everybody else, anyway.
Posted on 2007-10-27 03:29:15 by f0dder

Synfire: why isn't x64 == IA-64? Simple, IA-64 is intel's Itanium stuff, which is a completely different architecture from x86. Several years after Itanium, AMD decides to hack on 64-bit support to x86 which imho was a bad idea


That is not an entirely accurate statement. The IA-64 may have been planned for years before release, but AMD announced the x86-64 not even a year before Intel actually released the Itanium. Less than 2 years later after the first processor in the IA-64 series was released, AMD released the first processor in the x86-64 series. Less than a year later, and most likely due to dismal Itanium/Itanium2 sales, Intel announces that it is following suit in developing the their line of the x86-64 architecture.

I think AMD did a good job in patching the x86 architecture... more than they ever get credit for, by some.

What is so bad about slowly weening us off of the x86 in due time, anyhow???

Besides all of that, today's x86 processors are very different internally. They are more like RISC processors, just with CISC-like instruction sets. We are arguing semantics at this point.


(we finally had a chance to escape the clutchy x86 patchwork with the move to 64bit).


Well, the Itanium (IA-64) effort was not any better. Early on they marketed it for high-end computers, enterprise servers and what-not. How practical is that processor for desktop users... honestly???


Imho it should have been called x86-64 or x64, but it has sooo many names...


I guess that is why so many people insist on calling it the x86-64 or x64 architecture... to the point where I am starting to call the i386 architecture the x86-32 :P


AMD64 which is misleading because it's not a completely new thing (x86 instruction) and sounds like it's incompatible with x86 (which it isn't), the various names intel have been using for it, etc.


We developers are unique in that we actually care what goes on inside a processor. Most people are suckers for marketing and only care if the "latest and greatest" will run their existing programs.


Everybody plagiarizes everybody else, anyway.


Hmm... Yamhill -> Clackamas -> IA-32e -> EM64T -> Intel 64.

I am pretty sure Intel eventually convinced themselves that they are indeed the copyer this time, after decades of being the leader ;)

Hell, I used to be an Intel-only person, ever since the 386 came out. However, and IMHO, they dropped the ball as early as the Pentium 4. I took a chance on getting an AMD64, and guess what... it runs nice, cool and opened up a new world of possibilities to me. There was no looking back after being that pleasantly surprised :)
Posted on 2007-10-27 12:27:05 by SpooK
I feel roughly the same way as SpooK, although I first starting seriously looking at AMD when I bought a used K6 and then decided a K7 was a good investment. Granted, I was completely ignoring power use at this point. Back in the early 90's DEC's Alpha chips peaked some interest, and it was clear when AMD merged some of that technology they were going to produce something substantial.

Intel seems to always have had more research in chip production than design. With regard to x86 that is - all their best people worked on the Itanium design, imho. So, although they are following AMD's superior lead on x86-64, they are producing better chips at this point. AMD is changing up their design strategy again with SSE5 in an attempt to slow Intel's adoption of their designs.

Sadly, from a business standpoint, it is a loosing position for AMD unless they can find a way to produce their superior designs at the technological level Intel can.
Posted on 2007-10-27 16:43:44 by bitRAKE

I feel roughly the same way as SpooK, although I first starting seriously looking at AMD when I bought a used K6 and then decided a K7 was a good investment. Granted, I was completely ignoring power use at this point. Back in the early 90's DEC's Alpha chips peaked some interest, and it was clear when AMD merged some of that technology they were going to produce something substantial.


Peaked or piqued?


Intel seems to always have had more research in chip production than design. With regard to x86 that is - all their best people worked on the Itanium design, imho. So, although they are following AMD's superior lead on x86-64, they are producing better chips at this point. AMD is changing up their design strategy again with SSE5 in an attempt to slow Intel's adoption of their designs.


I personally think the SSE race has gotten out of hand. I guess that is the cost of keeping chip-producing companies in business.


Sadly, from a business standpoint, it is a loosing position for AMD unless they can find a way to produce their superior designs at the technological level Intel can.


Not entirely. AMD can continue to low-ball Intel on the cost of the final processor product in order to compete... and then we are back to status quo :P
Posted on 2007-10-27 17:28:13 by SpooK
I've always chosen the platform that made the most sense at the time - C=64, Amiga600, AMD 486dx4, Intel p200-mmx, AMD K6-2 350 (or was it 333? Buggy at any rate, but nice), Slot-A Athlon 700, Intel P4 northwood 2.53, AMD64 3500+, AMD64x2 4400+... And unless something radical happens, my next box will either be a core2 duo or a core2 quatro, depending.

I've also changed between ATi and NVidia, although I've been sticking with nv for the last few generations because of very nast ATi drivers. Anyway, that was just to point out I'm not a fanboi (in this regard, anyway ^_^).

Yes, Itanium wasn't marketed at end-users, price tag is too heavy and it's not really suitable for it (sure it'd run spreadsheets and browser and what 90% of end-users need, but pricetag + power consumption...), and the hardware x86 emulation was beaten by software emulation (typical of intel to screw up things like that). I'm not familiar enough with the architecture to say anything else about it, so I'm not saying it would be the perfect candidate for moving us over.

I do think AMD ruined or chances of escaping x86 anytime soon, though... the only thing that would be a big enough carrot (perceived or real) to move people over to a new arch, including pains of porting applications, was 32->64bit move. We aren't going to see anything of quite that magnitude for quite some time.

Yes, I'm very well aware that x86 CPUs are internally RISC, but what I wanted to escape is all the legacy hardware, the junky legacy crap in the CPU (16bit, segments, structures that are more complex than needed for 286 pmode compatibility, defunct hardware taskswitching, heck perhaps even paging). And perhaps a nicer instruction set with destination register and less hardcoded register dependencies, more unshadowed registers, getting rid of instructions that are faster to implement with multiple other instructions, etc.

But we're not going to get that now. Yeah yeah, backwards compatibility etc., but anything 64-bit produced now is fast enough to run legacy 32-bit applications that won't be ported just fine (okay, for games it might be different story).


I personally think the SSE race has gotten out of hand. I guess that is the cost of keeping chip-producing companies in business.

They're adding too many small things too fast, imho... they should focus a bit more on chip bugs and optimization (speeding up vmx, for instance), and then think through the SSE instructions a bit more. I think it's a bit weird seeing CPU crc support.


Not entirely. AMD can continue to low-ball Intel on the cost of the final processor product in order to compete...

How long can they continue to do that without going bankrupt? I wonder if the ATi merger was a good idea... the CPU/GPU integration is somewhat interesting, but mostly for OEMs and not enthusiasts, which tend to be the guys that buy AMD hardware.
Posted on 2007-10-27 18:19:31 by f0dder
They're adding too many small things too fast, imho... they should focus a bit more on chip bugs and optimization (speeding up vmx, for instance), and then think through the SSE instructions a bit more. I think it's a bit weird seeing CPU crc support.
AMD's SSE5 is a huge change: http://developer.amd.com/sse5.jsp

...not to mention it doesn't play well with recent Intel extensions. AMD certainly wants to bite off big chunks of Intel, but they're not in a position to chew. There has to be another piece to their stategy that isn't quite clear?
Posted on 2007-10-27 18:30:40 by bitRAKE
(...)SSE5(...)

FMADDPS seems to accelerate matrix multiplication. But what for? 90% of the GFX (and that's where the power is really needed) is done in hardware by the GFX card. I've been opting for the same things f0dder is: decrease the number of junk instructions ( == decrease the overall price) and then start thinking about adding something new. I don't see any use for like 40% of all current x86 instructions. I've been coding in ARM asm recently and found that many instructions can be executed conditionally. Now that's what I'd like to have in x86! Damn, even 8080 had a conditional call and conditional ret. And it had a "jump to an address stored in a register" in 1-byte instruction (it was perfect for loops). So why does x86 have a lot of junk instructions and very few 'nice' instructions? Someone should tell Intel and AMD what ASM programmers would really like to have ^^'


BTW: hi everyone, long time no see ^^'
Posted on 2007-10-28 16:24:31 by ti_mo_n