clear-cut 64 bits architecture ? (splitted)

[Candy]

</break>

I'm planning for the following subset of devices to have support in 4 years, and I expect this to be an accurate representation of a normal computer in 4 years in household environments:

- Processor of around 3ghz, with four or more threads running at once
- 2GB of memory or more
- RTL8139 or RTL8169 ethernet (it's cheap and it works good, and if you don't have it the cards are cheap as dirt)
- ATI or NVIDIA video card (that leaves me two drivers to write), plus BOCHS video card (for which I've already hacked the VGA bios to be able to program it from pmode and succeeded in testing it, using VBE mode)
- USB keyboard + mouse. Might include PS2 drivers if I care about it enough.
- AC97 soundcard plus possibly AC97 fax/modem. External ones could be supported, but I think that's not going to survive the next 4 years.
- Monitor that can do at least 1024*768. That rules out my laptops and my second monitor, so I expect that this might change to 800*600, but I hope not.
- CDrom/DVDrom/something-ROM drive complying with ATAPI on ATA-6+ or SATA.
- At least 40GB harddisk complying with ATA-6+ or S-ATA.
- USB2 controller

I have at the moment, for testing:
- Processor: AMD duron at 1200. Yes, it's due for replacement, will replace it halfway next year because I'll then have a lot of cash to replace it with. Hoping for a dual-core Athlon X2.
- 2GB of memory or more: 256mb DDR SDRAM. Needs replacement, see above.
- RTL8139 or RTL8169 ethernet: 1 8139 and 2 8169 cards. That allows enough testing and even destroying one of the 8169 cards (although I got two since a gbit switch is prohibitively expensive).
- ATI or NVIDIA video card, or BOCHS: ATI card I have (Radeon 9200SE), and I expect the bochs card to be present too.
- USB keyboard + mouse/PS2: Got all checked off. USB mouse as logitech cheapo and an MX1000 for myself, usb keyboard in two styles, ps2 mouse in at least 2 styles and I can borrow loads more, plus PS2 convert my MX1000 and the logitech cheapo, and I have a single PS2 keyb laying around (which might be a problem - try finding one ).
- AC97 soundcard/fax/modem: I have the soundcard, no fax/modem. Might do that when somebody asks for it, but I doubt it.
- Monitor that can do at least 1024*768: One. Hoping to get a TFT at 1280*1024 for christmas next year.
- CDrom/DVDrom/something-ROM drive complying with ATAPI on ATA-6+ or SATA: of course. CDROM doing atapi and DVD/RW doing at least ATAPI on ATA-6.
- At least 40GB harddisk complying with ATA-6+ or S-ATA: Exactly 40GB on ATA-6.
- USB2 controller: Got a UHCI on my laptop, OHCI and PCI EHCI on my main box

That gives me around 10 end drivers to implement for getting at least 10% of the target computer base fully functional, and up to 40-50% fairly running. For these devices, I have documentation for EHCI, OHCI, ATA, USB HCI, PS2, both RTL cards (one isn't public and I can't share it either, ask realtek, they're real nice people), AC97 (thanks to recent threads), AGP (thanks to intel and the OSFAQ), PCI (thanks to whoever put it online), the memory + controller and the processors (thanks AMD + Intel) and the Bochs video card (thanks to the open VGA bios).

So, that leaves me with the video cards. Yes, that's actually one really big show stopper. In the worst case, I'd have to implement a SVGA VLB driver, but I hope not. I think I'll implement the ATI driver first, based on the linux fb driver or the X.org driver, and then the nvidia (since I have an ati card, of course). I'm suspending this until I know which one survives the war in videocard land (expecting both however) or until it's the last thing I have to do.

PS: The bochs bios replacement sounds like a really really cool thing, are you going to make it open source?

- jeez, can't post the follow-up within 15 seconds?

[Brendan]

Hi,

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

In the last 10 years (between the beginning of PCI & USB and the beginning of 64 bit), the only thing that really changed was the speed of the components rather than any fundamental difference.

In the next 4 years I'm expecting an increase in the number of devices that use USB, a large increase in SATA usage, a large increase in multi-core/multi-CPU, and a large increase in 64 bit (80x86) CPUs. Apart from that I don't expect much else to change.

All of these are "in addition to" the existing stuff rather than "instead of". For e.g. you'll still have problems finding a computer without a floppy drive or PS/2, all CPUs will still support "legacy" protected mode, motherboards will still support PATA drives, ISA will still exist (but become even less common) and single CPU computers will still be around.

There is also some unusual stuff coming - virtualization, larger CD formats, 3D monitors, etc but IMHO none of it will dramatically change things for OS developers (except for DRM, which I'm hoping consumers won't want anyway).

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.

This is a matter of practicality I guess - no-one can write every driver that anyone could want. IMHO the important thing is to provide a kernel/OS that has enough functionality to allow all drivers to be written, and then write one driver at a time (starting with the "most needed", followed by the "second most needed", etc). The intention would be to get the OS functional enough (and well documented enough) that other people feel like writing device drivers too.

So, that leaves me with the video cards. Yes, that's actually one really big show stopper. In the worst case, I'd have to implement a SVGA VLB driver, but I hope not. I think I'll implement the ATI driver first, based on the linux fb driver or the X.org driver, and then the nvidia (since I have an ati card, of course). I'm suspending this until I know which one survives the war in videocard land (expecting both however) or until it's the last thing I have to do.

For me, video is one of the least important things. I usually have a "default video" driver which handles any video mode the user can select during boot. The default video driver just uses LFB and doesn't support video mode changes or anything. Without a proper video driver the OS/user can use almost all video modes, so proper video drivers aren't so important - the user just needs to reboot to change video modes and its slow because there's no 2D/3D acceleration.

PS: The bochs bios replacement sounds like a really really cool thing, are you going to make it open source?

Its already LGPL. Like most of my stuff its online in html form, and there's downloadable raw source code (tar.gz) and a binary image (.gz). The web page is "http://bcos.hopto.org/bios.html".

At the moment it has barely enough code to boot my OS (from floppy). It does dynamically create MP specification tables, the keyboard code is done and half of the BIOS setup menu is done ("Press DEL to enter setup").

It'll take me a long time before its "completed" though. Also, if you want to test it you may need to make minor changes to the Bochs source (I've been working with the Bochs developers to resolve issues like this, so eventually you won't need to change Bochs source).


Cheers,

Brendan

[Candy]

In the last 10 years (between the beginning of PCI & USB and the beginning of 64 bit), the only thing that really changed was the speed of the components rather than any fundamental difference.

In the next 4 years I'm expecting an increase in the number of devices that use USB, a large increase in SATA usage, a large increase in multi-core/multi-CPU, and a large increase in 64 bit (80x86) CPUs. Apart from that I don't expect much else to change.

All of these are "in addition to" the existing stuff rather than "instead of". For e.g. you'll still have problems finding a computer without a floppy drive or PS/2, all CPUs will still support "legacy" protected mode, motherboards will still support PATA drives, ISA will still exist (but become even less common) and single CPU computers will still be around.

Legacy is being kicked out of new computers. Quote from Dell, on a new computer (not one specifically picked for parallel or serial support, but just a random home computer):

Drive Bays
Externally Accessible: Two 5.25" for CD, CD-RW, DVD, DVD+/-RW4 or combination drive
One 3.5-inch bay for optional floppy drive or 9-in-1 media card reader
Internally accessible: Two 3.5-inch bays for hard drives

I/O Ports
1 front headphone jack
1 front microphone jack
8 USB 2.0 ports - 2 front/5 back/1 internal for media card reader
Serial ATA Ports: One 7-pin connector
1 integrated graphics port

Slots
2 PCI slots
1 PCIe x 1 slot
1 PCIe x 16 (graphics) slot

Chassis
Quiet, silver and white chassis features: 8 USB 2.0 ports (2 front, 5 back, 1 internal) and front headphone and microphone jacks

It doesn't have parallel, serial, ps2 ports. It doesn't have a floppy drive by default. It has onboard sound, which I'm going to bet is AC97. It has numerous USB ports, so I expect it to be used with USB keyboard and mouse. Onboard video, no idea which type. My bet is on some form of ATI, Nvidia or some other onboard manufacturer.

Legacy is already strongly going away in consumer devices. Consumer devices have a replacement duration between 2-6 years, so I expect most to be at least like this in 4 years. Also note that the default configuration for that one has three cpu's, all of which use HT. So, that's already 2 cpu's.

<gawd>

[Candy]

</gawd>

There is also some unusual stuff coming - virtualization, larger CD formats, 3D monitors, etc but IMHO none of it will dramatically change things for OS developers (except for DRM, which I'm hoping consumers won't want anyway).

Virtualization is the only one of those for which I'm possibly accounting. Note that I expect the virtualization to be combined with DRM to make the DRM effective. I think I might just not do the virtualization, but it depends on how it's implemented (and I don't have time to read it until next sunday or monday, so I can't reply on that with any more content for the next week).
3D monitors? For specialized needs only. Larger CD's don't change anything for a well-engineered OS (IE, don't try to store the capacity in a 32-bit, but other than that, nothing new).

This is a matter of practicality I guess - no-one can write every driver that anyone could want. IMHO the important thing is to provide a kernel/OS that has enough functionality to allow all drivers to be written, and then write one driver at a time (starting with the "most needed", followed by the "second most needed", etc). The intention would be to get the OS functional enough (and well documented enough) that other people feel like writing device drivers too.

Well... I'm not just trying to get those up, I'm trying to get at least a common subset of target computers running properly, so I'm going to get it running with one type of each first, and then in the order that I continually get the largest possible target base. I'd rather have 10% of computers working perfectly than 100% of computers working somewhat.

The default video driver just uses LFB and doesn't support video mode changes or anything. Without a proper video driver the OS/user can use almost all video modes, so proper video drivers aren't so important - the user just needs to reboot to change video modes and its slow because there's no 2D/3D acceleration.

My target is user/consumer, so that makes rebooting for mode changes rather unwanted for me. Such would require a specific driver, possibly cooperation with SaNiK on his VESA BIOS emulator.

Its already LGPL.

LGPL means that if I get one part, I get both.

I'll assume that's a yes for one part .

At the moment it has barely enough code to boot my OS (from floppy). It does dynamically create MP specification tables, the keyboard code is done and half of the BIOS setup menu is done ("Press DEL to enter setup").
...
Also, if you want to test it you may need to make minor changes to the Bochs source (I've been working with the Bochs developers to resolve issues like this, so eventually you won't need to change Bochs source).

For an AMD64 testing bochs, you need a few dozen compile options anyway, so there's no problem with that ;D.

[JAAman]

So, that leaves me with the video cards. Yes, that's actually one really big show stopper. In the worst case, I'd have to implement a SVGA VLB driver, but I hope not. I think I'll implement the ATI driver first, based on the linux fb driver or the X.org driver, and then the nvidia (since I have an ati card, of course). I'm suspending this until I know which one survives the war in videocard land (expecting both however) or until it's the last thing I have to do.

uh -- why not start with the most popular video controller on the market? especially when the official documentation is readily availible -- even for 2D/3D excelleration?

pop quiz:
what is the #1 video controller manufacter (controlling more than 50% of the market -- and a virtual monopoly in its market segment)







answer:

INTEL

[Candy]

uh -- why not start with the most popular video controller on the market? especially when the official documentation is readily availible -- even for 2D/3D excelleration?

pop quiz:
what is the #1 video controller manufacter (controlling more than 50% of the market -- and a virtual monopoly in its market segment)
answer:
INTEL

Oh I feel stupid now :S...

Intel would be quite a nice target for the video card... I'm not sure how often it's used on AMD64 devices however, and I have a feeling it's quite small. For my target it's quite probable however...

That solves the last point in between... now just to code it up and release it.

I'll be back. (shameless, isn't it?)

[JAAman]

i just realized your currently ignoring intel CPUs -- and currently intel video controllers are unavalible for AMD,

i just get so frustrated when people talk about unavalibility of docs for video controllers, when intel documents everything they do very well, and they are a signigicant market -- most people seem to forget and only think of ATI and NVIDIA when they do video controllers, not realizing that intel video drivers will satisfy a significant portion of the market -- most people don't need the high-end controllers and are happy with intels integrated controllers (which, as of the latest version, do quite well even in 3D excelleration)

when i get to it, i plan to support the intel graphics controller first for this very reason

[Candy]

i just realized your currently ignoring intel CPUs -- and currently intel video controllers are unavalible for AMD,

I'm not entirely ignoring them, I'm just kind of not knowledgeable about them... plus Intel has the reputation of being a market giant out to squash competition...

i just get so frustrated when people talk about unavalibility of docs for video controllers, when intel documents everything they do very well, and they are a signigicant market -- most people seem to forget and only think of ATI and NVIDIA when they do video controllers, not realizing that intel video drivers will satisfy a significant portion of the market -- most people don't need the high-end controllers and are happy with intels integrated controllers (which, as of the latest version, do quite well even in 3D excelleration)

I think I'm going to support an Intel platform first then, since it's the first platform I can get complete support for. Hoping ATI + NVidia open op however, since they do offer most of the stuff for AMD boards.

Now, anybody got a P4 with HT and dual-core for me? Nobody? hm... think I'm off saving again...

small ps: am I glad that all USB hubs for 2.0 are EHCI... that cuts down on half the development time...

[Candy]

From the recently-published-leaked-or-made-up-but-still-probable-roadmap from Intel:

Desktop Wolfdale Dual core, single die 3 MB shared 2008
Desktop Ridgefield Dual core, single die 6 MB shared 2008
Desktop Yorkfield 8 cores, multi-die 12 MB shared 2008+
Desktop Bloomfield Quad core, single die - 2008+

So... around 2008 two-core processors will be common, and shortly thereafter 4- and 8-core processsors will be introduced. My estimate for 2010 as rollout date does match with multi-core processors after all! ;D I'm kind of happy about it...

[Pype.Clicker]

seriously, who (will ever) need(s) 8-core on his desktop ?? i'd rather have a single core if they could make it --silent ...

[Rob]

I wouldn't mind having multiple cores. It should allow for a more responsive experience to everything. They are also going to introcuce multi-core Pentium M chips. Hopefully those are both "fast" and silent.

[Brendan]

Hi,

seriously, who (will ever) need(s) 8-core on his desktop ?? i'd rather have a single core if they could make it --silent ...

IMHO the problem with an 8 core CPU will be getting data into and out of it fast enough - cache miss latencies are bad enough for single core without delays caused by the additional traffic. Intel's solution to the latency problem is hyper-threading - do something else while your waiting.

Therefore, I wouldn't be surprised if the 8 core CPU has hyper-threading (a total of 16 logical CPUs).

Who will need this on the desktop? Probably no-one considering that most desktop software isn't multi-threaded enough. I'd use it in a server though....

I'd also expect these 8 core chips to be derived from Pentium M (otherwise it'd melt), and have Intel's virtualization (so it can run N seperate OSs).

BTW - if the number of transistors doubles every 2 years, how many cores will there be in 2020? I'm thinking there'll be 64 (or more) cores with a massive shared L3 cache...


Cheers,

Brendan

[Candy]

IMHO the problem with an 8 core CPU will be getting data into and out of it fast enough - cache miss latencies are bad enough for single core without delays caused by the additional traffic. Intel's solution to the latency problem is hyper-threading - do something else while your waiting.

Therefore, I wouldn't be surprised if the 8 core CPU has hyper-threading (a total of 16 logical CPUs).

Who will need this on the desktop? Probably no-one considering that most desktop software isn't multi-threaded enough. I'd use it in a server though....

My point is, this is explicitly the DESKTOP offering. The server offering went to 8-core in 2007 or before. It also has "2008+" on all 4+ core cpu's, which might be indicative of "when the market is ready for it" so it could be 2017 before they actually come out.

I'd also expect these 8 core chips to be derived from Pentium M (otherwise it'd melt), and have Intel's virtualization (so it can run N seperate OSs).

I expect them to have a smaller core that's clocked lower than a normal current CPU (say 1.5ghz), be based on a low-power design (P-M comes to mind) with one or two cores at a very high speed (3.5ghz or so). That way, single-threaded programs still get high speed whereas multithreaded programs actually do run faster.

I hope they don't mismatch the two too much because it'd decrease the point of more cores.

BTW - if the number of transistors doubles every 2 years, how many cores will there be in 2020? I'm thinking there'll be 64 (or more) cores with a massive shared L3 cache...

Now you're thinking.

The last one has a 12M shared cache, so that's a yes already.


So, back to the point of scheduling algoritms for dynamically using multiple processors...

[Brendan]

Hi,

My point is, this is explicitly the DESKTOP offering. The server offering went to 8-core in 2007 or before. It also has "2008+" on all 4+ core cpu's, which might be indicative of "when the market is ready for it" so it could be 2017 before they actually come out.

"When the market is ready for it" is right - the server market is ready now, while for the desktop market the CPU spends most of it's time waiting for a key to be pressed (or some other IRQ).

BTW - if the number of transistors doubles every 2 years, how many cores will there be in 2020? I'm thinking there'll be 64 (or more) cores with a massive shared L3 cache...

Now you're thinking.

The last one has a 12M shared cache, so that's a yes already.

12 MB shared by 8 CPUs isn't that much (an average of 1.5 MB per core). I'm thinking "massive" - 2 GB of cache shared by 64 CPUs (an average of 32 MB per core). The alternative would be bus frequencies of several GHz - fast enough to micro-wave a chicken with the resulting EMF interference (rather than the traditional convection heating Intel have been using lately).

So, back to the point of scheduling algoritms for dynamically using multiple processors...

Ok, some requirements for a scheduler:

• * must be aware of system topology (NUMA, hyper-threading, etc) and schedule threads accordingly to maximize performance.
  * must handle "CPU affinity" where a thread can be assigned to a single logical CPU, a single CPU core, a single NUMA domain or all CPUs.
  * should allow a CPU (or group of CPUs) to be marked as "exclusive", so that only threads belonging to the virtualizer or device drivers are run on them.
  * must handle "variable speed" CPUs (e.g. adjust scheduling according to thermal throttling).
  * should keep track of the amount of "relative time" each thread has used (rather than the amount of "real time" used). For e.g. if a thread runs for 1 second on a 2 GHz CPU, then another 2 seconds on a 1 GHz CPU, then it's used a total of 2 "virtual seconds" of CPU time.

Cheers,

Brendan

[Candy]

"When the market is ready for it" is right - the server market is ready now, while for the desktop market the CPU spends most of it's time waiting for a key to be pressed (or some other IRQ).

Well... the Windows gui has a load of overhead... and if you look at Apple's OS X it can't have low overhead either. The CPU's will be used. Time can only tell when multithreading will be normal...

My opinion is that it won't be on windows for quite some time. What's the point behind MTA, STA and free?

12 MB shared by 8 CPUs isn't that much (an average of 1.5 MB per core). I'm thinking "massive" - 2 GB of cache shared by 64 CPUs (an average of 32 MB per core). The alternative would be bus frequencies of several GHz - fast enough to micro-wave a chicken with the resulting EMF interference (rather than the traditional convection heating Intel have been using lately).

ehm... I'm hoping they skip the microwave-range... or that they make cases weighing in at 40kg again.

I would suggest a smaller cache in my opinion, with intelligent memory usage design. I'm working on a system that is supposed to pump around a high volume of data at my work, and I've come to the conclusion that multiple localized bits of memory are probably going to work pretty well... NUMA is a good idea.

Our problem at work right now is 2gbit/s coming in on PCI, with the top speed for our on-chip processors is 2gbits as well. The on-chip memory can pump at least 32 gbits so we're going to have to use some weird system design to get that working nicely. Esp. with multi-cpu's on a single chip which is required for our project.

Ok, some requirements for a scheduler:

• * must be aware of system topology (NUMA, hyper-threading, etc) and schedule threads accordingly to maximize performance.
  * must handle "CPU affinity" where a thread can be assigned to a single logical CPU, a single CPU core, a single NUMA domain or all CPUs.
  * should allow a CPU (or group of CPUs) to be marked as "exclusive", so that only threads belonging to the virtualizer or device drivers are run on them.
  * must handle "variable speed" CPUs (e.g. adjust scheduling according to thermal throttling).
  * should keep track of the amount of "relative time" each thread has used (rather than the amount of "real time" used). For e.g. if a thread runs for 1 second on a 2 GHz CPU, then another 2 seconds on a 1 GHz CPU, then it's used a total of 2 "virtual seconds" of CPU time.

1. System topology. Which works best, scheduling local (both on a HT proc), semi-local (both cores on a dual core) or remote (two separate domains in NUMA)? Or anything in between? For which types of threads? This is one of the things I'm very interested in, so if somebody can afford me a dual-NUMA space, dual-cpu dual-core HT machine, I'm more than welcome to do the testing. Although a machine with 16 cores would be pretty impossible to afford at this time. I'm hoping I can test at my work before I leave (got a dual xeon myself, sadly the model without em64t, friends work box is a dual athlon, athlon MP without em64t again).
2. Agree on this, up to a level. It should allow limiting to cpu types or areas. IE, only SSE3 capable chips, only chips directly connected to the IDE controller etc. I'm not counting this as especially important, since I see the future holding mainly identical processors (8-core cpu's will have mostly identical cores I hope). The access to the hardware should occur through asynchronous device drivers which work using memory anyway. It should be possible to hand the read function a page on which it can read, so it's in your local space. (of course, this is in atlantisos already).
3. Exclusive is a server-only thing. I can't help with that since I'm not going for servers. On the idea itself, that's a subrequest for the above. You must be able to indicate which processors a given process can run on based on any metric, so even user-specified checkboxes. So, see 2.
4. Variable speed is hard to do, although I have at one time intended to make the cpu allocations roughly in cycles, which would account for this entirely (except for the case of #STPCLK, but I'm not sure the tsc will keep counting then... I hope not).
5. Well.. see 4.