Talk:AMD64

FPU/MMX Registers

"Microsoft has chosen to not save the FPU/MMX registers across context switches in Windows XP 64-bit Edition for 64-bit programs "

Is this correct? I've seen quite a few MS blog entries supporting this claim but upon consulting the SDK from "Microsoft Platform SDK\Bin\win64\x86\AMD64\SWConventions.doc" Microsoft claims that MMX/Floating Point stack registers are preserved across context switches but MMX/FPU register use is stricly forbidden in kernel code.[section 2.3.7]

Perhaps this should read "...not save the FPU/MMX registers across 'all' context switches..." since I have no doubt it is (gladly) an attempt to obsolete FPU/MMX/3DNow instructions.

Bitbot 23:38, 16 October 2005 (UTC)[reply]

They're not saved across user/kernel transitions. They most definitely are saved across thread context swtiches. Fixed the article. Jeh 18:40, 5 December 2005 (UTC)[reply]

Ok, it seems someone else "corrected" things back. Fixed it again. I did some more research on this... the FPU/MMX registers are not saved across u/k transistions, but this was the case under x86 too. The real issue is that they are not saved when changing from, and are not restored when changing to, a thread that can only run in kernel mode. For example, the threads in the so-called "system" process. They most definitely ARE saved/restored when switching from/to all other threads, including threads running x64 code. I personally don't think all of these details belong in the article, as these are Windows internals details and the article is about AMD64, not Windows.... Jeh 04:55, 5 January 2006 (UTC)[reply]

Running x86/MMX/3DNow! instructions in 64-bit mode is not supported by AMD programming reference, the Windows SDK has no support for compiling both intrinsics and assembly code that uses these instructions on 64-bit plaform, so there's no need for Microsoft to support it. It's all outlined in Porting and Optimizing Applications on 64-bit Windows for AMD64 Architecture whitepaper right on the WHDC: 64-bit Platform site. And using math instructions in the kernel haven't been supported on ANY Windows platform, so there's no even need to notice.

But of course you're free to apply your "common sense" everywhere and remove any non-obvious content without even Googling the keywords first, all in all, it's a "free encyclopedia" you know (sarcasm). --DmitryKo 14:40, 9 January 2006 (UTC)[reply]

You have valid points and I focused too much on what the OS code is doing, and not on what developers should do. I've changed the Windows point accordingly, and just left out the whole issue of why... which is probably better for this page anyway.

Math instructions are perfectly usable in kernel mode in Windows in certain circumstances. That is what the DDIs KeSave/RestoreFloatingPointState are for (see DDK docs), or their Eng equivalents, the latter being available to graphics drivers (and very commonly used).

Finally, as for the CPU, the most recent version of the AMD programming docs ( from http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_7044,00.html ) say "x87 floating-point instructions can be executed in any of the architecture’s operating modes" (volume 1, section 6.1.2) and "The x87 instructions can be used in legacy mode or long mode. Their use in long mode is available if the following CPUID function bit is set to 1:" (volume 5, section 2 intro -- and that bit IS set on my two Opterons and on my amd64). The same verbiage appears in the hardcopy versions I have, which are slightly older. Do you have another reference that says otherwise? Jeh 01:06, 12 January 2006 (UTC)[reply]

And the issue continues...

Locke Cole added a comment to the article: " source for this ; I think early documentation indicated this was true, but in actual fact it's not? "

As DmitryKo pointed out above (and see the paper he linked at microsoft.com), it is not *supported* by Microsoft. None of the Microsoft compilers, etc., will generate x87 instructions, for example.

The early reports that were wrong were the claims that the OS would not save/restore x87 machine state in long mode. It does save and restore them, and furthermore x87 instructions will *work* in long mode. They'll even work in kernel mode in long mode, as long as you are careful to use the DDIs I mentioned. But MS doesn't support their use in long mode. Jeh 18:11, 15 January 2006 (UTC)[reply]

Thanks Jeh. The reason I mentioned it was that I'd read a blog entry on blogs.msdn.com (that I cannot find now) indicating that Microsoft had backpedaled on ditching FPU/MMX support. But obviously if I cannot find it, the article should stand as it is. =) —Locke Cole • t • c 18:29, 15 January 2006 (UTC)[reply]

And yet again...

In response to MirrorVax's deletion of the "they're not supported" statement I've added an amplified explanation. MirrorVax, if you have substantiation for the dispute, please post it here? Jeh 22:15, 16 January 2006 (UTC)[reply]

Well, you were the one doing the disputing. I'm agreeing with you. Mirror Vax 00:51, 17 January 2006 (UTC)[reply]

Oh, ah. I retracted that stance, at least as far as "what developers should do" is concerned. Probably I should have closed with that point instead of following it with "but, those opcodes WILL work!" Anyway I hope the main page is adequately clear now.

I'm still researching exactly why these instructions "aren't supported" -- but I have good reason to believe it has to do with stack usage and exception handling, as opposed to context switches. Jeh 01:19, 17 January 2006 (UTC)[reply]

Address Space Limits

About the claim :

"Due to the 64-bit architecture, the AMD64 architecture can address up to 256 tebibytes (also known as terabytes) of memory "

so 64 bits matches an 1.9... * 10^19, so about 19 Exa byte, so about 19'000'000 terabytes ! So could someone correct that claim or explain why the real addressing space is not as long as the theoretical addressing space ? If it's something like a practical adaptation to the largest size of memories in scope, it's a real shame, because I think we can't exclude Exabyte memories on a single computer, especialy because of the theoretical molecular limit of about 1.02 * 10^23 is still further away 5'000 greater which leaves 5'000 molecules for a mole of matter storing 19 Exa byte of memory, probably accessible with a volumetric memory based on nanotechnologies. Another reason would be the short life of a processor family making it unlikely to survive a 256'000 scale of memory evolution.

Best greetings LF

The AMD64 architecturally supports up to 2⁵² bytes of physical memory and up to 2⁶⁴ bytes of virtual memory. Current implementation only supports 2⁴⁸ bytes of virtual memory and 2⁵²(AMD) or 2⁴⁰(Intel) bytes of physical memory. But the implementation limit could be lifted easily when necessary.Zuxy

Go read the Architecture manual, what you are saying is pure rubbish, the CPU supports a flat -non segmented virtual address space of 2⁶⁴ bits. Physically it handles 2⁴⁸ or 2⁵² bits. Dont get the limits confused, what you are saying is highly erroneus. So in Virtual memory speak its 64-bits. —The preceding unsigned comment was added by Lordofacid (talk • contribs).

No, you are mistaken. Although virtual addresses are 64 bits wide, in current implementations (and for any chips known in the planning stages) you cannot populate that entire space. Valid ("canonical") virtual addresses run from 0 through 7FFF`FFFFFFFF, and from FFFF8000`00000000 through FFFFFFFF`FFFFFFFF. The high 16 bits of the address are ignored during address translation, except that they must be copies of bit 47 (in a manner akin to sign extension), or an exception will be raised. So, although the addresses are indeed 64 bits wide, and all 64 bits must in fact be specified, only 48 of them are really usable. This was done to cut down on the number of address translation steps, i.e. to reduce the cost of a TLB miss. Hence 2⁴⁸, or 256 TiB usable virtual address space (of which 64-bit Windows is only populating a total of 16 TiB....) Jeh 19:06, 30 July 2006 (UTC)[reply]

...updated the main page accordingly. I see a number of additional "implementation details" that could be added, such as page table entry format, a map showing the four-level (9 bits per level, plus 12 bits of byte offset in page = 48 bits total...) address translation scheme, details on how the REX prefix works, etc. Then this new section would become a subsection under an "implementation details" section. Jeh 19:38, 30 July 2006 (UTC)[reply]

AFAIK 32 bit x86 CPUs support up to 32 + 16 - 2 (or maybe -3?) of Virtual memory space. 32 bit of offset, and (16 - 2) of segment (-2 because of the two priviledge level bits). True that this assumes flat memory (CS=DS=ES, etc.) is not used. Thus, 32 bit CPUs can access Virtual Memory space of 2⁴⁶, which can be accessed when running more than one process.

In practice, Windows 32bit, for example have the following [[1][limits]] .

Wrong. At least in the 32-bit x86 architecture, the segmentation system doesn't allow access to more than 4 GiB (32 bits) of memory. This is because 1) the segmentation mechanism runs on top of the virtual address space, which is 32-bit, and 2) segments are not used like you assume: in real mode, "addresses" (offsets) can be 20 to 32 bits long (real/extended real mode), and the address is formed like this: segment*4 + offset. In protected mode, however, segments are defined by structures called segment descriptors stored in either the GDT or the LDT, and the address is formed like this: descriptor.base + offset. Those structures are 32-bit oriented, and thus won't allow addresses longer than 32 bits by themselves. The only way of having them is via the Physical Address Extension (PAE) mechanism, which allows the computer to have up to 36 bits of physicall addresses, mapped to the 32-bit virtual space using paging.

In the AMD64 architecture, however, and when in 64-bit long mode, addresses are always 64-bit, the segmentation mechanism is mainly deprecated (save GS and FS, of which only the base is used) and PAE paging is always enabled. The 256 TiB figure is because the AMD64 spec allows processors not to implement all the address bits: they can have as little as 48-bit of virtual addresses and 40 bits of underlying, paging-mapped physical addresses - current AMD64 processors are more or less like this. All addresses formed must be canonical as stated in the article, which, as the pictures explain, allow a neat positioning of both kernel and user code, not to talk of later extensibility. :Habbit 17:25, 19 September 2006 (UTC)[reply]

One could support 46-bit segmented addresses within a 32-bit linear address space; one cannot, however, have more than 2³² bytes worth of the 2⁴⁶-byte segmented address space resident in the linear address space at any one time, so one would have to swap segments in and out of the linear address space in response to, for example, "segment not present" traps, and every reference to a swapped-out segment would involve a trap plus whatever operations are required to move other segments out of the address space to make room for the new segment to be moved in, as well as whatever operations are required to move the new segment in. That would be the case regardless of how much physical memory you have; all that additional physical memory would do for you would be to reduce the number of I/O operations to backing store required - it would not reduce the number of segment swap operations required.

So, in practice, while one could support a 2⁴⁶-byte address space, most, if not all, OSes don't bother. Guy Harris 06:17, 20 September 2006 (UTC)[reply]

Let's take a look at x86's way of translating a program-specified "memory address" into ones and zeros on the (max) 36-bit physical address bus, and how are some "usual" addresses specified and interpreted (you can check this in the Intel manual, order# 253668):

 segmented address space (16b sel + 32b offset)    <--- any normal program address                    |
 segmentation                                                                                         |
 linear address space (32-bit)                     <--- some special system addresses (i.e. GDT base) |
 paging and PAE                                                                                       |
 physical address space (32 to 36-bit)             <--- CR3 base address                             \|/

Paging and PAE can be disabled, effectively skipping them (and limiting the physical space to 32 bits). So, in fact, you could design an operating system that allows each process to have some 16380 segments (i.e. using up all the descriptors in both the GDT and the LDT) of 4 GiB each, working with one at a time, and performing some gigantic page switches to allow accessing them all. That gives you an address space of nearly 32 + 14 = 46 bits, yep, but it's not worth the trouble of designing compilers with segmentation support, especially when you can have an AMD64 with a 48bit virtual address space (4 times the memory of your "46 bit" x86). Habbit 15:54, 20 September 2006 (UTC)[reply]

64-bit integer arithmetic

I think having native 64-bit integer arithmetic should also be mentioned in the "Some of the changes" list, because it's really one of the most fundamental changes (right?). intgr

You're right. Done. Jeh 18:40, 5 December 2005 (UTC)[reply]

Ancient History

Isn't the 8-bit processor 8085 and not 8088?

Well, the 8088 had an 8-bit data bus... --Brion 10:33 Jan 13, 2003 (UTC)

See, the page 8088 itself says 8088 was based on 8086, but this page seems to imply the opposite.

I hope the latest version clarifies the situation. 8080 -indirectly-> 8086, then 8086 --> 8088 --> 80x86 in general.

EM64T Not Identical?

Can someone substantiate the claim that EM64T is not entirely compatible with AMD64, and that it was based on an earlier revision of the AMD64 spec? If not, I think we ought to can it. --Doradus 15:33, 26 Aug 2004 (UTC)

Have a look at http://www.maximumpc.com/reprints/reprint_2004-04-07b.html Seems there are some subtle differences. Mhowkins 18:50, 26 Aug 2004 (UTC)

Thanks for the link. Unless I missed it, the article doesn't say what the differences are. I know there are some system-level differences, but I'm not aware of any application-level differences. --Doradus 15:51, 28 Aug 2004 (UTC)

Ok, have a look at http://www.devx.com/amd/Article/20960, and http://www.infoworld.com/article/04/04/07/HNintelamdties_1.html

According to these articles, the Intel processors do not support the LAHF and SAHF instructions in 64-bit mode, because an early release of the AMD docs said the architecture would not. AMD later changed this statement, and support for these instructions was added to their processors. The other article implies that these instructions are used for context switching, so the difference is probably only relevant to O.S. kernel developers. Mhowkins 18:44, 28 Aug 2004 (UTC)

Interesting. My manuals at the office must be an older edition. Looking at the specs freshly downloaded from AMD, they say nothing about LAHF being unsupported. Thanks for the link. --Doradus 02:09, 29 Aug 2004 (UTC)

The rewrite

(Doradus) Can anyone explain why the article was gutted and rewritten? I think the version before the rewrite was much better.

It seems like the user "Bad Byte" is the one who did this (and I later joined in, refining the separation of content). It was in an attempt to separate the earlier article into information about hardware implementing AMD64 and the AMD64 architecture itself. I think that the AMD64 article should be primarily about the AMD64 architecture, and articles like Athlon 64 and Opteron and Intel Xeon should be about the hardware implementing AMD64. However, as the hardware implementing AMD64 is relevant, I support the current list of products implementing AMD64, with links to the articles.

I think that the "supported operating systems" information from previous reincarnations of this article really needs to be brought back. That's important information this article shouldn't be without, and I think I'm going to get started writing this list.

Samrolken 17:23, 16 Oct 2004 (UTC)

(Doradus) Ok, sounds good to me. Carry on. :-)

Article title

AMD64 is centered around AMD. On the other hand, EM64T is centered around Intel. Why not just call it x64 and make AMD64 and EM64T redirects? - Sikon 15:24, 28 September 2005 (UTC)[reply]

As far as I know, "X64" is a Microsoft coinage. Some would say there are more than enough Microsoft-centric references in the article already. ;) Jeh 06:44, 6 December 2005 (UTC)[reply]

Why not call it x86-64, this way it doesn't show bias toward Microsoft, Intel or AMD. Coldpower27 23:47, 17 June 2006 (UTC)[reply]

The current organisation makes sense to me - AMD64 is the particular architecture designed and named as such by AMD, and thus this page is the primary source of information, while the EM64T article just talks about Intel's implementation of the architecture. -- intgr 01:44, 18 June 2006 (UTC)[reply]

Absolute garbage

What idiot mucked about with this page? This person clearly does not know one end of a PC from another. I can accept the world is full of ignorant and stupid people, but why oh why screw up a perfectly good page, and insert total nonsense? I've written tons of content for the PC section in the WIKI, AMD, NVIDI, ATI, so I'm not taking this lying down.

...a straightforward extension of the x86 architecture to 64 bits

Eh? So eliminating the FPU is just extending the x86 architecture? Er, no. Actually, its the biggest change to the x86 architecture since the i386 rolled out - and some would argue more significant. I'm going to put back a lot of the old content, my content, before the article got ruined and rendered technically inaccurate. I can't be bothered to find out who did this - whoever you are, read this, take note, put it down to experience, and take your ignorance elsewhere.

Right, done the deed. You know you have a crank, when stuff about AMD's advertising in the Netherlands, turns up in what should be a technical article. If we added a discussion of how AMD's CPUS are marketed in every country in the world, then where oh where would the madness end? Timharwoodx 20:38, 8 October 2005 (UTC)[reply]

Thanks for restoring the stuff with your 8 Oct edit. -R. S. Shaw 20:43, 10 October 2005 (UTC)[reply]

Sigh...I'm the one who attempted to clean up the article, only to have the nonsense and disorganization added back by Timharwoodx. That you write "tons of content" does not impress me. Your edits are, frankly, terrible. They are factually wrong, as well as wordy, opinionated, and disorganized.

Having made the damning charge above, I guess I have to give at least one example to illustrate the point. Consider: While it was considered at one point RISC chips would inevitably replace the outdated and quirky x86 architecture, in fact AMD64 effectively turns x86 into a modern RISC type programming environment. The genius of AMD64, is that it undertakes this major architecture upgrade, while retaining legacy compatibility. Total nonsense. To the extent it is something other than pure opinion/babble, it says that AMD64 includes a RISC-like instruction set. That is false, and it's a mistake that anyone with the slightest knowledge of the subject would not make.

Then we have the curious question above, "So eliminating the FPU is just extending the x86 architecture?" I can't make any sense of that. Again, total nonsense. Not even wrong. Mirror Vax 11:52, 27 November 2005 (UTC)[reply]

Having thought about it more, I conjecture that he is saying that AMD64 drops the x87/mmx instructions. That is false; they are included. Further, even if it were true, it would not be an earth-shattering development. SSE2 is not new with AMD64, remember. Mirror Vax 12:26, 27 November 2005 (UTC)[reply]

I agree with Mirror Vax (and I'm an old VAX hacker too!). More relevant: I actually work with AMD64 chips and systems at the OS kernel and device driver level. I've removed nearly all of the RISC references (there is utterly NOTHING RISC-like about AMD64!) and am gradually removing some of the rest of the apparent fanboism. Jeh 18:45, 5 December 2005 (UTC)[reply]

Binary vs. Decimal prefixes

This article is confused on this point. For example, it says "256 terabytes", when the actual number is about 281 terabytes -- 256 tibibytes. In my edits this evening I tried to clarify things by adding the powers of two. Is that suitable? Jeh 17:02, 16 November 2005 (UTC)[reply]

What seems doubtfull to me

1) AMD64 (also x86-64 or x64) - x64 is Microsoft's term, not AMD's one. IMHO it would be consistent ether to remove non-AMD terms (AMD64 (former name: x86-64)) or include all the terms (AMD64 (also x86-64 or x64 or EM64T))

2) Marketing analizes section: AMD is told to never extend IA-32 instruction set. That is false! Remember 3DNow! and PowerNow! The real difference is that previously intel ignored AMD innovations and coupled them with it's own incompatible ones later (SSE instead of 3D Now! and SSE was told to be better technically, SpeedStep and later Enhanced SpeedStep instead of PowerNow! ST was worse, EST about the same), and for AMD64 intel did not developed it's own non-compatible 64-bit extensions. It is Intel's behavior that made difference, not AMD's one.

BTW, not the same is going about La Grande and VanderPool, but i would not say if it was AMD or Intel 1st in those extenseion and their analogues.

MS Biased article?

Does this article seem rather MS Biased? There are 12 references in this short article to "Windows", and 3 references to "Microsoft".

Compared to a single reference to the alternative operating systems that support the AMD64 instruction set. Seeing how MS was the last OS vendor to even support the architecture.....

This is a valid point. I'm certainly not the person to do it; I'm a Windows kernel guy (and, in the past, a VMS kernel guy). If someone wants to provide authoritative information on the details of how, for example, Linux, for example, uses AMD64's features, the "edit" button is up there for you to use. ;)

In that case I'd think the right thing would be to create a new section, "Operating system support", and gather all of the present refs to Windows support under there along with the new material. Hm.... Perhaps I'll do this anyway with the Windows material as it will clean up the existing text where it is now, and provide a good place for Linux (or other OS!) folks to add their stuff. Jeh 22:16, 5 December 2005 (UTC)[reply]

... done, as far as Windows is concerned. Contributors other than me are needed to fill in the others. Jeh 04:40, 13 December 2005 (UTC)[reply]

Heh... Considering the number of OSes out there, and the number of "OS vendors" in existence, I think it's more reasonable to say that Microsoft was one of the first to support x86-64. WinNT just came behind the major open-source *nixes, which is, I think, what you meant. -- uberpenguin 19:26, 13 December 2005 (UTC)[reply]

Removed features - V86 mode?

The "Removed features" paragraph says that Virtual-8086 mode was removed in 64 bit mode. Yet the chart right below it says that 16 bit applications are supported in the new 64 bit mode. What's the right answer? -- Myria 07:50, 23 December 2005 (UTC)[reply]

Note that Virtual-8086 mode and 16-bit code do not have to be the same.

V86 mode allows real mode apps (16-bit code) to run under protected mode, while protected mode can be 16-bit or 32-bit.

If in long mode it is able to run real mode code I don't know (Windows preferred to simply ignore it).

—Claunia 09:04, 23 December 2005 (UTC)[reply]

Did you confuse 32-bit processing with protected mode? 286 supported protected mode but was still 16-bit. Yuhong 06:45, 31 December 2005 (UTC)[reply]

See http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24592.pdf, page 9

No-Execute bit

It should be noted that a similar feature has been available on 32-bit x86 processors since the 80286 as an attribute of segment descriptors.

The 80286 was 16-bit, not 32-bit. Do only 32-bit 80386 and up have segment descriptor attributes, or was it also in the 16-bit 80286?

MSTCrow 06:05, 25 December 2005 (UTC)[reply]

Ever since the 80286, x86 processors have always had two separate categories of segment registers - one for code and one for data. You can only ever execute from a "code" segment, meaning that "data" segments are never executable. In fact, you cannot mark a "code" segment as writable, either. In this way, Win16 is more protected against buffer overflows than Win32. In Win32 and most other 32-bit operating systems, there is a separate code segment, but it maps to the same address as the data segment used in DS, ES, and SS, and segment registers aren't used for, well, segmenting memory anymore. -- Myria 23:54, 25 December 2005 (UTC)[reply]

Compare page

Can somebody do a compare page of AMD64 versus EM64T? I would really appreciate that, thanks! :)

See the EM64T page - in particular, see the Differences between AMD64 and EM64T section. Guy Harris 01:50, 4 February 2006 (UTC)[reply]

Links

I've added links to other wikipedia resources, please finish the work I started if i can't do it

(update) Opps, o forgot my sign

--Ciro07 11:42, 1 February 2006 (UTC)[reply]

You've added links to pages that already contain links in this article. There's really no need for such duplication - only the first occurrence of an article should be linked, and only if its relevant to the topic. I'm reverting all but one of these additions. Mind matrix 16:41, 1 February 2006 (UTC)[reply]

AMD 64 problems in float computing

I have heard about the AMD 64 processers that they have problems in computing float numbers.If any one have any idea,I'll be be happy to know.Tanx.

  Saham Hendinejad--Hendinejad 10:45, 23 April 2006 (UTC)[reply]

[hendinejad@gmail.com]

What kind of problems, exactly? References? A quick google search turned up nothing relevant. If it's about errors, it's a problem with the specific CPU design and not the AMD64 architecture. Single- and double-precision floating point calculation of AMD64 and x86 is specified in the IEEE 754 standard. As for x86 full-precision (80-bit) FP arithmetic, the corner cases are pretty much unspecified and all programmers using these ought to be aware of potential issues. -- intgr 14:13, 23 April 2006 (UTC)[reply]

I think that is a reference to this news item[2][3], which affects certain "AMD Opteron 152, 154, 252, 254, 852 and 854 processors manufactured in late 2005 or early 2006", which are generally only used as server CPUs. -- Bovineone 22:40, 29 April 2006 (UTC)[reply]

Common Use vs. Stuff Nobody's Ever Heard Of

Honestly, now, who put Gibibyte in there? Is this a joke? —The preceding unsigned comment was added by 72.12.219.114 (talk • contribs).

I don't like it either. Your heading nailed it. The only reason I've not reverted it is because, sadly, consensus seems to be against us. jgp (T|C) 19:28, 28 June 2006 (UTC)[reply]

The wikipedia Manual Of Style says that the new prefixes are "recommended for use in all articles where binary capacities are used" -- Bovineone 04:54, 29 June 2006 (UTC)[reply]

Consensus against us?! If all wikipedia users were polled, I'd expect people to prefer what they see in a computer ad to what they see in the 37th page of an IEEE spec. I guess it really comes down to accessibility vs. technical accuracy, and the intended audience. How much jargon (gibibyte) should we let in, alienating the common man (gigabyte)? I hate the hard drive industry's power of ten lies as much as everybody else, but I really don't think this is how to fix it. --Johnruble 18:45, 29 June 2006 (UTC)[reply]

Sorry but it is not the "hard drive industry's power of ten lies." "giga" means 1,000,000,000 and an 80 GB hard drive really does contain 80,000,000,000 end-user bytes -- usually a bit more. And Windows will even show you that number, if you look in the disk properties. Yes, in many Windows displays MS uses the "GB" prefix improperly, dividing the drive capacity by 2^30 instead of by 10^9, showing the capacity as "73 GB"... nevertheless you can still store 80 billion of your bytes on the drive. Tell me, would you still consider the HD makers liars if they put "80 billion bytes" on the box? Er, wait, that's exactly what they're saying. Jeh 23:12, 30 June 2006 (UTC)[reply]

Allow me to rephrase. Replace 'lies' with 'deception.' The only place I've ever seen gigabyte used to portray one million bytes is on a hard drive box. --Johnruble 01:33, 2 July 2006 (UTC)[reply]

I'm sure you meant to type "to portray one billion bytes", but anyway... Turn it around: The only place that "giga" ever means 2^30 is when the prefix "giga" is followed by "byte." What you're arguing is that it's perfectly fine for the same prefix to mean different things for different units of measurement: One km should remain 1000 meters, a megawatt should be 1,000,000 watts, one GHz should still be 1,000,000,000 cycles per second... at least, I hope you would agree to those... but one GB should be 1,073,741,824 bytes. That's frankly ridiculous, no matter how long the computer industry has promulgated it. SI prefixes have been around just a *bit* longer, you know?

Furthermore there is no motivation to use binary prefixes with hard drives. There is absolutely nothing about a hard drive that requires or even encourages the capacity to come in powers of two (as there is with RAM), so why should a binary prefix be reasonable?

As for "deception," the only point of discrepancy is in the digits on the HD box vs. the digits displayed by Windows; after all, Windows WILL show you the capacity down to the byte, it does jibe with what's on the HD box, and it also jibes with the number of bytes Windows will let you store.

As for what people expect, ask a random sample of 100 PC users to write out the size of a "300 GB" hard drive without the "GB" and I'll bet 90% of them write "300,000,000,000 bytes." (If they are not sure how many zeroes the "G" prefix represents, ask them to try it with a "1.42 KB" file.) Similarly, most people are not aware that a "256 MB" DIMM does not contain 256,000,000 bytes, but slightly more.

Personally I think it's the RAM makers -- and, of course, ALL displays in OSs -- that should change. Back when RAM was measured in KB the discrepancy was small, but at the GB level it's almost ten percent. And wouldn't the RAM makers love to change their labels to say, for example, "268 MB"? Of course they would! Everybody's reported installed RAM sizes would increase too. It would be like a free upgrade!

You wrote "If all wikipedia users were polled, I'd expect people to prefer what they see in a computer ad to what they see in the 37th page of an IEEE spec." Don't you think Wikipedia should aim a bit higher than computer ads?

Seriously, the HD makers could address the issue very simply: in addition to saying "1 GB equals 1,000,000,000 bytes" on the box, they could also say (for a 300 GB drive) "this drive provides at least 300,000,000,000 bytes of usable storage (displayed by most operating systems as 279 GB)" Jeh 03:02, 2 July 2006 (UTC)[reply]

The confusion between 1000 and 1024-base units has gone on long enough, and is becoming more and more important since the ratio between these units gets greater with larger prefixes. Introducing new units is the only real way to solve it, and I would expect most people to be intelligent enough to realize the relation between terms "megabyte" and "mebibyte" or much more so for MB vs MiB. These new units are also linked on most pages in case anyone is unsure. In my opinion, this is the way to go, and Wikipedia should be progressive in adopting new and positive initiatives. FYI, in addition to harddrive manufacturers, all networking hardware (eg, 100Mbit/s Ethernet meaning 100 000 000 bits) and internet connection speeds reported by most ISPs (not all, to add to the confusion) use 1000-base prefixes as well. -- intgr 11:07, 2 July 2006 (UTC)[reply]

re. comm speeds -- Exactly. Similarly, a "100GB native" LTO2 cartridge holds 100 x 10^9 bytes, not 100 x 2^30. So I was too broad above; "binary" prefixes are not even common with all uses with "bytes," it's really only "bytes of RAM" where they are used consistently. There are just two possible solutions that make sense: One, OSs should change to use binary prefixes in all displays where they are now using powers of 1024, and should display file and hard drive sizes with the correct decimal prefixes using powers-of-1000 divisors. Or, two, OSs would change to use powers of 1000 in all cases, and RAM makers would relabel their products, so e.g. a "256 MB" DIMM becomes "268 MB." I actually like the latter solution better, as it maintains consistency. I think the RAM makers would like it too *grin*. Jeh 13:06, 2 July 2006 (UTC)[reply]

You guys make good arguments. I suppose it's pretty ridiculous for me to wish to overload the definitions of metric prefixes when talking about bytes, though that's how I'd like it to be. Some day I'll have kids who have pebibyte ipods, and I'll be the old man, resisting change, refusing to start using the new prefixes. --Johnruble 19:08, 2 July 2006 (UTC)[reply]

Architectural features to tertiary headings?

I am looking at the "Architectural features" section and thinking that it would be much easier to edit if bolded items were subheadings. Would that upset anybody? It might (as in maybe, I don't really know) make merging easier. --Charles Gaudette 21:57, 3 September 2006 (UTC)[reply]

Shouldn't the date be mentioned

The article does not say when the 64-bit was introduced...

From my readings, it was first introduced as a concept in 2000, and produced in 2003 as Opteron and Athlon64

BUT, I'm not sure

Shabayek.com