Talk:64-bit computing/Archive 1

This is an archive of past discussions about 64-bit computing. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Unsorted

(Anonymous) I think this article could really use some peer review. There appears to be a lot of semi-referenced (for lack of a better term) information and what may be personal knowledge written in. I don't know what the Wiki tag is for "peer review" or "please get an expert to clean this article up." Thanks.

—Preceding unsigned comment added by 173.69.166.131 (talk) 14:31, 31 May 2009 (UTC)

This entire article needs simplifying at least at some point, preferably early on. We need a very dumbed down explanation of what is being discussed. It is way way too technical.

Agreed, I can't figure out the main difference to a 32bit processor in practical terms, and I've been into computers for the past 10years. 202.180.121.229 (talk) 09:44, 13 March 2008 (UTC)

Why is there marketing on an otherwise wonderful page:

2005: On April 18, Beijing Longxin rolled out its first x86-64 compatible CPU, named Longxin II.

What follows that is little more than a bad advertisement for who cares what. Please think of removing it. Dshard 03:44, 6 November 2005 (UTC)

From comp.arch Usenet group:

That page had so much wrong with it, it just wasn't worth starting to fix (people with more 64-bit experience than me should do that).

Aggh! This needs to be updated by "those who know" then. The PowerPC's 970, used in Macintosh's G5 has been released for about two years, but in a weird coda to this article (I'm guessing it's an unmerged duplicate?) we say "The PowerPC ..[is].. expected to move to 64 bits at [its] next generation - PPC 620 ", which is a generation or two ago. Other parts may be similarly out of date. - Nunh-huh 03:12, 13 Apr 2004 (UTC)

There should be some merging and moving around of articles, I think. The general description of what it means for a CPU, bus, or piece of software to be n-bit applies equally to 64-bit, 32-bit, 16-bit, and even 8-bit, so shouldn't be duplicated in a bunch of articles (where to best put it?). The 64-bit specific stuff should stay here, of course. --Delirium 04:30, Apr 13, 2004 (UTC)

I agree with the above, regarding n-bit. Not sure what a good name for the common article would be. Perhaps separate ones for addressability and for datapath widths (eg. ALUs, word sizes, register sizes, program variables).

Plus, the "pro/cons" section needs some serious copy-editing. Maybe I'll dive in some time and start hacking when I have some free time...--Doradus 02:38, 25 Aug 2004 (UTC)

Proposed title
Perhaps they could go under processor classifications' or processor taxonomy? -unknown user/date

[2005-06-22] ATTRIBUTION FOR FIRST DRAFT OF TIMELINE:
Timeline text from anonymous (unattributed) internet poster, posted November 2004 on the South Dakota BIT website. -- Liberty 22:52, 22 Jun 2005 (UTC)

2038 Problem

I suggest mentioning the 2038 problem and solution with 64 bit systems (small advantage) atleast somewhere in the text —Preceding unsigned comment added by Whendrik (talk • contribs) 12:05, 12 July 2009 (UTC)

Minor edit in Section: 32-bit vs 64-bit

(My summary got cut off, too long.) Removed sentence/paragraph:

Also, 64-bit processors calculate particular tasks (such as factorials of large figures) twice as fast as working in 32-bit environments (given example is derived from comparison between 32-bit and 64-bit Windows Calculator; noticeable for factorial of say 100,000).^{[citation needed]}

Reasoning:

Has been flagged as Citation Needed
Is redundant and probably widely known: 64-bit processors are an advance in technology and an improvement over 32-bit processors; therefore, it follows that certain software or tasks may perform better in a 64-bit environment.
Does not follow logical flow of the sub-article; it seems to be inserted at random, a point unrelated to the surrounding paragraphs.
Run-on sentence

SilentAshes (talk) 07:48, 17 April 2009 (UTC)

Fair enough, I agree. Dravick (talk) 08:06, 18 April 2009 (UTC)

Incorrect point

From the article:

Some operating systems reserve portions of each process' address space for OS use, effectively reducing the total address space available for mapping memory for user programs. For instance, Windows XP DLLs and userland OS components are mapped into each process' address space, leaving only 2 or 3 GB (depending on the settings) address space available under Windows XP, even if the computer has 4 GB of RAM. This restriction is not present in 64-bit Windows.

This suggests that said OS components don't use up memory, but they do. Also it is inconsitent in use of RAM/memory.

If one has 4 GB of memory, then 32 bit is enough. Let's say OS components take up 1 GB. Then there is 3 GB memory left and also 3 GB address space, so all is well. Note that the operating system may also reserve memory outside of the process' address space and that multiple processes may be running, so 4 GB of process' address space may even be enough when one has more memory.
If one has 4 GB of RAM, then one has at least 4 GB of memory. Whether a larger address space is needed depends on how much of the extra memory is munched up by the OS outside of this address space etcetera, as already stated before.

The point stated in the article is only valid if the OS reserves portions of the process' address space that it doesn't actually use. Shinobu 16:35, 8 August 2005 (UTC)

No. Address space and RAM are different. Address space can be used by other things besides RAM, including PCI memory mapped registers, and virtual mappings. For example, if you mmap() a file most of the file won't be paged into RAM, but all the address space associated with that mapping is now in use. Also, the same RAM can be mapped in one than one place. So it's very easy to need more than 4GB of address space if you have 4GB of RAM available. Mostly the recommendation is that you should switch to a 64-bit address space before you have 2GB or so of RAM or you'll regret it. You can see the gymnastics needed to use 4GB or more of RAM without a 64-bit CPU in Linux and Windows systems using Intel's PAE CPU extensions - you can actually end up making an application slower by adding more RAM with this sort of approach. 82.69.171.90 (talk) 15:54, 17 March 2008 (UTC)

Atari Jaguar

Interested in this point:

have a look at this site: [1] It states that the atari had a 64-bit RISC based processor at its core and this was back in 1991!! is this correct?

I remember that thing. It might be a useful starting point about defining exactly what "64 bit" really means. It also makes the point that more bits does not necessarily mean more processing power - the game system was ultimately less powerful then Sony's Playstaton 1. Algr 03:40, 26 February 2006 (UTC)

(Out of order replies can be confusing.)

No. Jaguar's CPU is a Motorola 68000, a 16/32-bit processor. It has additional graphics coprocessors, some of which have 64-bit width somewhere, but that's not the same thing. Kaleja 05:31, 16 September 2006 (UTC)

The Jaguar heavily stressed it's 64 bit nature in it's advertising, as opposed to the 32 bit PS 1 and Sega Saturn. Apparently they were defining something else other then the 68000 as being the "CPU". I recall some press skepticism about this - It was more about marketing then technology. That is what I meant above about "defining exactly what "64 bit" really means."Algr 05:08, 17 September 2006 (UTC)

Pros and cons

What are the pros of 64 bit? This article is 100% useless without explaining or mentioning the advantages of 64 bit. It amazes me that not one single word was written about this. —Preceding unsigned comment added by 66.1.44.180 (talk) 05:50, 31 March 2008 (UTC)

How about straightening out this unintelligible gibberish?

Are you talking about the entire section, or just the "64bits Linux vs 32bits linux system" part? Guy Harris 22:39, 23 January 2006 (UTC)

Another pro for 64-bit systems, which is important in real-world software, avoidance of virtual address fragmentation. It is often difficult to allocate a single huge section of memory in 32-bit systems, because DLLs and other chunks of memory are often scattered througout the address space, breaking free space into smaller regions. This was done to permit rapid loading of DLLs without conflict and remapping.

Although not an address issue, many programs run faster on 64-bit systems because more registers are available to the compiler in the x64 Intel/AMD architecture.

Does Linux belong in this heading? It would be more informative (somewhere) to discuss the history of 64-bit UNIX in general, with dates, and not just Linux. What was the first 64-bit UNIX? When did UNIX on the PC go 64-bit?

Microsoft moved toward 64-bits in stages, and it would be nice to document that. Windows NT on the Alpha and MIPS had partially 64-bit capabable, but didn't support 64-bit user processes really. Some Microsoft Server systems permitted a sort of overlay capability to access more than 4GB -- ugly but it should be mentioned. Cutler was famous for enforcing 64-bit compatability in the kernel, so what other issues presented problems of Windows, before true x64 versions of Windows could appear? DonPMitchell 01:04, 22 February 2007 (UTC)

Memory Mapping

This statement sounds pretty far-fetched:

Memory mapping of files is becoming less useful with 32-bit architectures, especially with the introduction of relatively cheap recordable DVD technology.

If the idea is true, perhaps "large media files" or something similar makes more sense to discuss. -Justzisguy 23:43, 24 April 2007 (UTC)

Size of 64 bit memory space

The wikipedia article, as of August 17, 2006 claims 64 bit memory can address 16 exabytes or 17,179,869,184 gigabytes. These numbers should read exabits and gigabits respectively in order to be correct.

Um, no. Memory on all modern machines is addressed by byte, not by bit. Kaleja 05:31, 16 September 2006 (UTC)

Even with the change it would be a bit unusual to see the term gigabit as defined 2^30 * 8. Data transmissions typically use gigabit defined as 10^9 and data storage typically defines gigabyte as 2^30. While a plausible definition of gigabit, 2^30 * 8 is not a definition commonly used by users in either the data transmission field or the data storage field. It would be more correct for people interested in memory capacity to say that 64 bit memory can address 2,147,483,648 gigabytes or 2 exabytes.

As a refresher, using the common defintions for memory storage:

1 byte = 8 bits

1 kilobyte = 2^10 bytes or 1024 bytes

1 gigabyte = 2^30 bytes or 1024^3 bytes or 1,073,741,824 bytes

1 exabyte = 2^60 bytes or 1024^6 bytes or 1,152,921,504,606,846,976 bytes

2^64 bits = 18,446,744,073,709,551,616 bits

Given that there are 8 bits in a byte you need to divide this number by 8 to get the number of bytes that can fit in a 64 bit space

2^64 / 8 = 2,305,843,009,213,693,952 bytes

Now we can figure out how many of any order of bytes fits into the above number of bytes:

kilobytes in 64 bits = 2^64 / 8 / 1024 = 2,251,799,813,685,248 kilobytes

megabytes in 64 bits = 2^64 / 8 / 1024^2 = 2,199,023,255,552 megabytes

gigabytes in 64 bits = 2^64 / 8 / 1024^3 = 2,147,483,648 gigabytes (the wikipedia author mulipied this number by 8 to arrive at 17,179,869,184 giga[bits])

terabytes in 64 bits = 2^64 / 8 / 1024^4 = 2,097,152 terabytes

petabytes in 64 bits = 2^64 / 8 / 1024^5 = 2,048 petabytes

exabytes in 64 bits = 2^64 / 8 / 1024^6 = 2 exabytes

64 bit memory space, by some defintions, is considered to address 16 exabits (not bytes) of memory. This makes some sense because 2 exabytes * 8 bits/byte = 16 exabits. As noted, this assumes an uncomon definition of exabit.

If you prefer to count bits by their base 10 defintions, more typical of data transmission than data storage, the numbers would be:

2^64 / 10^0 = 18,446,744,073,709,551,616 bits

2^64 / 10^3 = 18,446,744,073,709,552 kilobits

2^64 / 10^6 = 18,446,744,073,710 megabits

2^64 / 10^9 = 18,446,744,074 gigabits

2^64 / 10^12 = 18,446,744 terabits

2^64 / 10^15 = 18,447 petabits

2^64 / 10^18 = 18.4 exabits

The above reflects a misunderstanding of how processors address memory. Addresses are byte addresses. A 64-bit address would mean using 64-bits to address a byte. A 64-bit value has 2^64 possible addresses and so a system with 64-bit addresses can address 2^64 bytes.

64-bits in a byte address mean you can address 2^64 different bytes because a 64-bit register has 2^64 different values, each one representing a byte.

Theoretically, one could have a 64-bit processor address a quad-word with each value. So '1' would mean quad-word 1 and '2' would mean quad-word two. In this case, 2^64 possible addresses would mean 2^64 possible quadwords or 2^64*4 possible bytes. Such a CPU could plausibly be designed and with 64-bit addresses could address more then 2^64 bytes. This is typically not done (because it's usually necessary to address characters and storing a character in a quad-word is a waste of memory). I just point it out to show that there's no reason a 64-bit CPU should only be able to address 2^64 bits. The two measurements are measuring different things. 64-bits means 64-bit registers, not that bits are being addresses by the values in those registers. —The preceding unsigned comment was added by 206.171.168.138 (talk) 07:16, 14 December 2006 (UTC).

SILP64

? Seen here: [2]. I suppose it means that short,int,long,pointer are all 64-bits? Here are a couple references Google found, from gcc mailing list: [3] [4] probably somewhere in gcc source-code it could be seen, I don't know. So I'm adding it to the article with a citation-needed and link to this section of the talk page, as well as a redirect SILP64 -> 64-bit. The references I have found at least make it clear that it is related to ILP64/LLP64/64-bit stuff. —The preceding unsigned comment was added by Isaac Dupree (talk • contribs) 16:17, 17 December 2006 (UTC).

Cray

Some Cray machines (e.g. Cray Y-MP EL) was 64-bit in early 90s.. should we mention them? --Yonkie 17:59, 20 January 2007 (UTC)

Yes, definitely, there needs to be some mention of pre-Alpha/R4000 architectures. Letdorf 17:50, 15 February 2007 (UTC).

Control Data systems, from around 1960 on, were based on 60-bit architecture. Just 4 bits short of making it into this article! More importantly, many of those early large-word machines (60 or 64 bit) had small address sizes (18 bit or 24 bit, etc). So they were not fully 64-bit architectures in the modern sense. DonPMitchell 01:12, 22 February 2007 (UTC)

I've added the CDC and Cray architectures (also IBM Stretch and Elxsi) to the timeline. Might also be worth mentioning the first CMOS "Crayette" implementation? (SCS?) Letdorf 10:35, 22 February 2007 (UTC).

Windows Vista

I think this page could use some information on Windows Vista 64-bit. —The preceding unsigned comment was added by 84.92.62.165 (talk) 17:43, 5 February 2007 (UTC).

The page is about 64-bit computers in general. The appropriate place for information on 64-bit Windows Vista would be the Windows Vista page (and the same applies for 64-bit versions of other OSes). Guy Harris 01:55, 28 February 2007 (UTC)

Damage

What is going on with this page? Beginning of the second paragraph is AWOL! Who is overseeing the changes? You need to do something and change it back to an earlier version. 71.255.51.87 01:39, 28 February 2007 (UTC)volkan

This is the Wikipedia; there's nobody overseeing much of anything. I've fixed the damage in question; there's no need to revert the entire page to do that and, in fact, reverting the entire page would lose useful changes. Guy Harris 01:55, 28 February 2007 (UTC)

Sun 64-bit support

The section about Sun's 64-bit sounds plausible, but doesn't square with facts from the Sun web site.

Fact: The speed of the compiler doing compiles has nothing do with the startup speed of an app.
Fact: As of Java 1.4, the JIT compiler is supported on Solaris but not Windows.

--Stosh --152.160.16.68 17:47, 16 March 2007 (UTC)

"data model" reference is incorrect

The term "data model" is made into a link, but the target page has nothing to with this topic. Either make the phrase not be a link on this page, or disambiguate the target page.

FWIW, "data model" is the best term I can use the describe the difference between a "32-bit program" and a "64-bit program". —The preceding unsigned comment was added by 192.18.43.225 (talk) 02:38, 4 April 2007 (UTC).

Opinion Removal

From the last paragraph in Memory limitations:

Apple's Mac Pro, for example, can be physically configured with up to 16 gigabytes of memory, and as such there is no need for support beyond that amount. A recent Linux kernel (version 2.6.16) can be compiled with support for up to 64 gigabytes of memory.

The statement "...there is no need for support beyond that amount." is an opinion, and it should be removed.

--HockeyInJune 16:46, 15 September 2007 (UTC)

It doesn't mean "nobody would ever need more than 16GB of memory on a Mac Pro", it means "you can't physically configure a Mac Pro with more than 16GB of memory, so there's no need for an OS running on a Mac Pro to support more than 16GB of memory". If, for example, a new Mac Pro came out which could be configured with up to 64GB of memory, there would be a need for support beyond 16GB. Guy Harris 21:19, 15 September 2007 (UTC)

Moores Law Mistake

The article says that Moores law dictates that computing power doubles every 18 months, this is incorrect it doubles every 24 months as it says on even wikipedias own article. http://wiki.riteme.site/wiki/Moore%27s_Law 90.200.150.1 15:55, 4 October 2007 (UTC)

They do refer to the 18-month doubling period in the body of the article. In any case, the exact value of the period has never been measured, as far as I know. Of course, the point of the law is that the power increases exponentially; however, since this section relies on the exact length for the calculation of time periods, it is a relevant point. Cema 20:47, 11 October 2007 (UTC)

Moore's Law isn't even a law. It's some guy making an observation. I don't think it should be included in the article, or if it is included, it should be worded differently (i.e. it's an observation, not a rule from on high). - Theaveng 13:03, 15 October 2007 (UTC)

Well, there is a law of nature and there is a law of jurisprudence, and then there is a "law" in the everyday parlance which refers to a practical rule based on observation and incomplete induction. Moore's law is of the latter type, and indeed it may be important to emphasize it. Cema (talk) 07:07, 7 April 2008 (UTC)

Regarding the Atari Jaguar

I have recently noticed that there are a few individuals making edits to the 64 bit processor timeline by adding the Atari Jaguar, even though it has been discussed before. The provided justifications for its inclusion is wrong for these reasons:

It has been mentioned that the Jaguar is 64 bit because of the width of its address and data buses. But the width of the address or data bus of a CPU is irrelevant, because it does not mean that the CPU can manipulate values that are the width of these buses. To back up this statement, I will provide examples:

The Intel Pentium is a 32 bit CPU - with a 64 bit data bus. Intel datasheets describe the Pentium as a 32 bit CPU because it is a fact. The Pentium's integer registers are still 32 bit, and thus, the CPU only manipulates 32 bit values. To avoid any confusion regarding this example, the Pentium I am referring to is the original 1993 model.

The DEC Alpha 21164 is a 64 bit CPU - with a 128 data bus. Digital and industry literature describes this CPU as 64 bit for the same reasons as the Pentium.

The HP PA-8000 is a 64 bit CPU - with a 36 bit address bus. HP literature, as well as industry literature, describes the PA-8000 as a 64 bit CPU because it has 64 bit integer registers and can manipulate 64 bit values.

The current line of Intel and AMD 64 bit CPUs also have address buses of a lesser width than their integer registers - yet we do not refer to these CPUs as anything else other than 64 bit, for the same reasons as the PA-8000.

It has also been mentioned that the Jaguar is 64 bit because of the width of the registers and execution units in the graphics hardware. While the graphics hardware are processors, they are not CPUs, which is what the timeline in this article is about.

For example, a computer with a 32 bit Pentium 3 processor and a graphics card containing a GPU of a different register width (say 64 bit) does not make the computer 64 bit. Why? Because the integer register width of the Pentium 3 is still 32 bit and the integer execution units (ALUs) can still only manipulate 32 bit values.

So with all this, why should the Atari Jaguar be included in a timeline for 64 bit CPUs? Rilak (talk) 22:27, 19 November 2007 (UTC)

At least one such edit cited the second paragraph from the instance of the "N-bit" template in the article. The invocation of that template was removed from the article, but this argues that the template needs to be fixed, so it doesn't suggest that a CPU with an N-bit address or data bus is an N-bit CPU, at which point we can put the invocation of the template back. Guy Harris (talk) 22:39, 19 November 2007 (UTC)

I put a section into the talk page for that template asking whether it should de-emphasize bus widths (or more clearly explain where they are, and aren't, relevant). Guy Harris (talk) 22:48, 19 November 2007 (UTC)

Thanks for adding that the talk page of the template. Back to the Jaguar, I would like to point out that the latest round of edits don't add anything to justify it being here. Firstly, how does a collection of graphics hardware, a DSP and a bootstrapper processor justify it being a 'multiprocessor system'? Secondly, the references are not reliable as since they consist of a picture of an advertisement, which could have been altered, and a link to a page whose contents contain errors, misconceptions and inaccuracies. I think the references the Atari Jaguar needs for inclusion are technical documents from reliable sources, such as datasheets for the chips or industry literature such as the Microprocessor Report. All the other entries in the timeline can be referenced in this manner and I don't see why the Jaguar should be exempt from this. If anyone knows where to find such information, please add a link for us here. —Preceding unsigned comment added by Rilak (talk • contribs) 11:08, 20 November 2007 (UTC)

That's complete nonsense on the picture being "altered". The Jaguar was advertised as a 64-bit system, and there's plenty of other resources for those pamphlets and further advertisements, a simple google search blings up a plethora. And advertisement of the Jaguar is not a valid reference for a statement that it was advertised as 64-bit? Secondly, the document referenced is a well known document amongst Jaguar programmers. Here is a link containing all the current programming documentation as well as original Atari Corp. Developer documents. The Atari Corp. document also has a demo coding showing the 68000 as a bootstrap device, showing how its used to coordinate sending code to the other processors. Here's a reference talking about the origins of the Jaguar as a multiprocessor system, Here's another page discussing it as a multiprocessor system and its history, and the problems with some developers simply porting 68000 based games and using that as the main processor (there are also plenty of other pages that discuss this problem, that a simple google search brings up). Here are two non-gaming pages mentioning it as a multiprocessor system while discussing other multiprocessor technology. [5] [6]. There is of course also the Jaguar FAQ. The same multiprocessor design was also carried in to VM Labs' Nuon, which was designed by the same people who designed the Jaguar. --Marty Goldberg (talk) 16:48, 20 November 2007 (UTC)

"A fool and his money are soon parted." An advertisement is not a valid source of technical information (if it was, we'd be led to be believe the PS3 is a 1024-bit CPU... it is not). "Advertisement" is just another word for "lie" and not a valid source. ---- Neither is a FAQ that merely regurgitates the lies coming out of Atari's Marketing department. C'mon. Your references don't pass the validity test.

BTW, and just to satisfy my curiosity, if the 68000 is not the CPU, then what is? None of the other devices have the capability to execute machine code. What were programmers supposed to use to run the games? - Theaveng (talk) 21:58, 20 November 2007 (UTC)

Once again, an advertisement is not a valid reference for a statement saying the Jaguar was advertised as 64-bit? Because that's what it was being used as a reference for. It was not being used as a "technical reference", but even if it was its still valid as a resource as to what the company is claiming in their system. Luckily you don't decide what's a valid resource here. And yes, the two 64-bit chips in question run their own code. Again, the 68000 was designed to function as a coordinator, fetching the code to run on the custom chips. Likewise, all developer documentation refers to the two 64-bit processors in question (contained in the custom TOM chip) as "processors", each with a 64-bit RISC core, registers, etc. In no way does any of the documentation refer to the 68000 as the "main" cpu, nor does it refer to it in any capacity other than a coordination or support capacity. Again, the documentation even shows how to use the 68000 to load code to the other processors. In fact, it in no way states any one of the processors as the "main", because its stated as a multiprocessor system. Please do a little research of actual development and coding process of the system before making those kind of statements again. I've provided several sources above, not just the "advertisement" and "faq". And the burden is on *you* to find a reliable source stating the 68000 was designed to be the "main cpu". That does not mean a source that states some programmers simply used the 68000 because the multiprocessor setup was to hard to code (as one of my sources also states), which is most of what you'll find out there. And the fact that you call information "lies coming from Atari's Marketing department" also has little bearing and constitutes WP:OR - its your personal opinion. --Marty Goldberg (talk) 22:38, 20 November 2007 (UTC)

Here's another direct reference as well regarding the multiprocessor design and the use of the 68000 as bootstrapping for the other processors.

From the Intro to the dev system (page 1):

"Featuring 64-bit technology and multiple custom RISC processors..."

Jaguar Software Reference Manual, June 7th, 1995, Atari Corp. In the section "What is Jaguar" (page 1):

"Jaguar is a custom chip set primarily primarily intended to be the heart of a very high performance games/leisure computer." Additionally: "As well as a general purpose CPU, Jaguar contains four processing units". "Jaguar provides these blocks with a 64-bit data path to external memory devices..."

Under "How is Jaguar Used" (page 2):

"The (68000) CPU is used as a manager. It deals with communications with the outside world, and manages the system for the other processors".

--Marty Goldberg (talk) 04:41, 21 November 2007 (UTC)

More biased sources (atari sources and/or regurgitation of atari literature). As example, you wouldn't go to the Windows Vista page and use Microsoft as a source that Vista is "a safe secure environment". Everybody knows Microsoft is a bias and unreliable source, and that you should go to a non-microsoft source. Same with the Jaguar; Atari is not a valid source. - Theaveng (talk) 11:17, 21 November 2007 (UTC)

Firstly this timeline is about devices that are 64 bit in the proper definition (that being it has 64 bit integer registers and execution units) and adding an entry just because it was advertised as 64 bit doesn't cut it. If such reasoning was used, I could make a 4 bit processor and advertise it as 128 bit and thus be praised for building the first device of that kind. This is why advertising is not a valid reason. I suspect, from the tone of the supporters of the Jaguar, that you think that I am excluding the Jaguar for some reason, and that is entirely incorrect. Wikipedia is about reliable references, and so far none have been provided (community FAQs, blogs and the like are not reliable) and there is the question of the actual architecture of the Jaguar.

As for the accusations of me not doing my research and providing a biased view, that is also completely incorrect. Advertisement is unreliable as I have stated for the reasons before. As for me not doing my research and thus I should be 'burdened' - do stop making these utterly false comments - I cannot understand why this discussion cannot be civil - I have not insulted any of you, but in return I get comments stating that I do not get a say here, that I don't do my research, that I am biased - I did not even say that the 68000 was the main processor, if you read my comments correctly.

As for this statements "Jaguar provides these blocks with a 64-bit data path to external memory devices..." I do not appreciate it when comments I type, for the purpose of making articles better, are utterly ignored becuase you do not agree. Please read my first comment regarding this issue, I have provided a good explaination of why busses don't count.

"Featuring 64-bit technology and multiple custom RISC processors..." and "Jaguar provides these blocks with a 64-bit data path to external memory devices..." - These statements only says that it features 64 bit technology, it doesn't say where - it could be in the buses, anywhere, but is it in the integer registers and execution units.

"Jaguar is a custom chip set primarily primarily intended to be the heart of a very high performance games/leisure computer." and "As well as a general purpose CPU, Jaguar contains four processing units". - You have proved it - the Jaguar is not a multiprocessing device but a chipset, which is technically correct. A multiprocessing system is a HP Integrity or a Boxx Apexx. Further more, you have also stated and proven that the Jaguar only contains one general purpose processor and four additional ones for graphics, sound I believe, this also furthers the fact that it is not a multiprocessor system. Now, the second statement says there is one general purpose CPU - provide a datasheet or some technical reference for that and so the matter of it being 64 bit or not can be solved. Rilak (talk) 11:22, 21 November 2007 (UTC)

"Again, the 68000 was designed to function as a coordinator, fetching code to run on the other chips..." Translation: 68000 is the Central Processing Unit and the other devices are merely the "slaves" to the 68000. Similar to the relationship between a Pentium and it's video GPU or sound chip. Just because I install a 64 bit Video GPU in my system, does NOT make it a 64 bit computer. It's still a Pentium, and still only 32 bits. - Theaveng (talk) 11:41, 21 November 2007 (UTC)

This is addressing Rilak and Theaveng together. Theaven, these were direct quotes from the developer manuals, not marketing material. These are the references developers use to develop software for the system and understand how it works. The manufacturers own developer manuals are *the* verifiable standard on their own hardware, and use regularly as references on Wikipedia. Wikipedia does *not* run on Theaveng's viewpoint as to what he wants to make valid and not. Rilak, the statements at not doing research were not addressed at you, it was addressed at Theaven, who keeps making edits based on personal opinions and WP:OR, and whose conduct here and in edits on other articles is currently under review. Rilak, these *are* the data sheets. And yes, the manuals do go on to state *where* the 64-bit technology is, its been repeated here already. And again, these manuals directly state it as a multiprocessor system. Likewise, it states there is one general purpose cpu for managing the other processors (i.e. the code that goes to them), and even states the 68000 is external to the actual system (i.e. its usage as a bootstrapper). Not "there is one CPU for the system". Additionally, I had already stated the two 64-bit processors have their own registers, and internal execution units, and execute their own code. Its also in the manual already provided as a reference. Likewise, an advertisement *is* a valid reference for stating the system *was advertised as 64-bit*. Anything you keep guys wanting to state to the contrary regarding how you interpret the info in the developer's manual is your interpretation, and WP:OR unless you can find verifiable references that support that view. I'd even accept the addition of a statement regarding criticism of the unit as being 64-bit to make the passage neutral, *if* you provide a valid reference regarding it. --Marty Goldberg (talk) 14:19, 21 November 2007 (UTC)

I keep hearing people say, "The manual say this..." or "The manual says that..." but I have yet to see any manual placed before me, so I can review it. Does this manual even exist? If so, I want to see it. I don't think that's too much to ask. - Theaveng (talk) 15:03, 21 November 2007 (UTC)

(cur) (last) 14:57, 21 November 2007 Wgungfu (Talk | contribs) (27,182 bytes) (The direct link was given at the 64-bit discussion.) (undo)

(cur) (last) 14:57, 21 November 2007 Theaveng (Talk | contribs) (27,570 bytes) (Undid revision 172914628 ---------- I don't see any Zip files. Give me/us the direct link.) (undo)

Okay. Where's this so-called link to a Zip file of the Jaguar Development Manual? I came here, I checked the links, but I don't see this zip file. - Theaveng (talk) 15:01, 21 November 2007 (UTC)

My first response in this discussion contains all the links. Obviously you didn't check the links. And once again, Wikiepdia citations for books *do not* require weblinks. --Marty Goldberg (talk) 15:03, 21 November 2007 (UTC)

Firstly, Wgungfu, regarding my misunderstanding of your comments, I apologise for that, it was a honest mistake, it was in my view at that time that those were directed at me. Since they are not, I apologise once again.

As for my opposition as well as those of others regarding the inclusion of the statement about the Jaguar being advertised as 64 bit, and its associated references, they should not be included in the timeline as the timeline is about devices that are 64 bit, instead of advertised as so, regardless of whether the device is 64 bit or not. For example, there are no references or statements about, say for example, the POWER3 being a processor advertised as 64 bit, even though such advertisements did exist in IBM literature for systems that used the POWER3.

As for the Jaguar being 64 bit, yes, I have acknowledged that some parts are. I have found sources that state that the blitter and object processor were 64 bit with 64 bit registers. But what I do not understand, is why the Jaguar should be in a timeline for general purpose CPUs. I think that some people believe it should be included because those components could be used to execute code other than what they were intended to do. However tr must be considered that GPUs in PCs can also be programmed to perform functions other than graphics, such as accelerating a physics calculation, but systems with 32 bit processors with or using these GPUs do not qualify as being 64 bit.

Further more, I have come across statements from other sources that mention that the Jaguar is 64 bit because the blitter and object processor reside in the same chip and package as the GPU. Before that gets used as a justification here, I would like to point out that the Intel Pentium 3 and the the entire x87 architecture, I believe, feature 80 bit floating point registers and a floating point unit capable can perform double precision operations. But this doesn't qualify the Pentium 3 as 64 bit, even though the 64 bit FPU and the 32 bit ALUs reside on the same die and package much like the Jaguar's GPU.

As for the 68000, I have not found reliable sources for this yet, but the sources that I have found seem to suggest many games that used the 68000 for AI, logic and management purposes. Whether that is true or not still needs to be research, verified and debated, but it would seems to me as of now that the 68000 was indeed the CPU (feel free to disagree, but note that I said 'seems to me as of now') and it is certainly not 64 bit.

Regarding the inclusion of the the 64 bit memory controller and buses in the timeline, I think those should be removed for now for reasons I've stated at the very beginning of this discussion. As for the the Jaguar being a multiprocessor system, in the tradition and perhaps proper sense, it is not. I think this is because computer and game console terminology might be different, but a collection of a general purpose/bootstapper processor, GPU and DSP is more like a 'chipset', or 'platfrom' than a multiprocessor system (compared to 'true' multiprocessor systems such as AlphaServers, HP Integrity servers, SGI Origins or SMP workstations). Rilak (talk) 15:13, 21 November 2007 (UTC)

Rilak, I appreciate the response and continued discussion. I would support the removal of the other non 64-bit related topics. However, the two processors in question are not GPU's, there is an actual separate 32-bit processor labled as the system's GPU. I also did not see anything in the entry summary regarding this just being about 64-bit general purpose CPUs, rather it described 64-bit processors. --Marty Goldberg (talk) 15:20, 21 November 2007 (UTC)

I thought the Atari Jaguar had five 'processors' contained within three chips, with the GPU, blitter and object processor built into one chip, on the same die, while the 68000 and DSP were separate chips. Did I get this wrong? As for the timeline, processor usually refers to general purpose processors. Whether it does or not is not clearly stated, but since most other editors have only included general purpose processors (no GPUs, DSPs ASICs) in the list, it would be safe (in my opinon) to assume that the list is for general purpose processors. Rilak (talk) 15:30, 21 November 2007 (UTC)

That's correct, same die, different processors/architectures. Three of the processors (the 32-bit gpu, and the two 64-bit blitter and object processors) were manufactured in a single custom chip. Unless you're interpreting my stating "separate" to mean they are on a physically separate chip. Regardless, I've removed the paragraph for the time being until this is sorted out. --Marty Goldberg (talk) 15:35, 21 November 2007 (UTC)

Perhaps I did interprete them as being separate. I think I was trying to say that since these three processors or components were on the same die and chip, it does not mean that it qualified the whole chip was as being 64 bit. I think I said it just in case someone decided to offer that as justification as I had come across that a lot during my search for references and more information. Rilak (talk) 15:47, 21 November 2007 (UTC)

That means my Commodore Amiga 500 is not really a 5 processor machine (68000, Agnus, Paula, Denise, Gary). It's an 8 processor machine (...blitter, sprite, DSP). Cool. - Theaveng (talk) 15:42, 21 November 2007 (UTC)

Yup, and my computer is a multiprocessor machine also because I have my sound card DSP (emu10k2) and so on... And it's also at least a 256bits computer because I can use my graphic card as a GPGPU and run Folding@Home and it has a 256-bits bus. Not to mention my good old Pentium 1 is actually a dual core because it has an arithmetic co-processor on the same die —Preceding unsigned comment added by 82.246.86.215 (talk) 18:40, 4 February 2008 (UTC)

I'm going to add Commodore 64 to the article (it has "64" in it; right?). - Theaveng (talk) 15:16, 21 November 2007 (UTC)

Now you're just confusing things. The 64 in Commodore 64 refers to the amount of its built-in memory, but nobody has ever claimed that it's a 64-bit machine. There's nothing 64-bit about the C-64. It's a much clearer-cut case than the Jaguar. I would advise you to avoid disrupting Wikipedia to make a point. — KieferSkunk (talk) — 23:53, 21 November 2007 (UTC)

No, he doesn't. It is your assumption that the 64 in C64 refers to the RAM size. That's a fair assumption and likely true but there's no evidence that it's actually a fact. For example, the C16 has 16 KiB RAM and the C128 has 128 KiB RAM by default but the C116 has no more than 16 KiB RAM. Obviously you cannot take for granted that this number has a strong meaning. If you wanted to sue Commodore over the missing 100 KiB, you'd most-likely lose the case. The Jaguar was advertized as "64-bit". Yes, just that. You can also find the video ads on YouTube. Some say "64-bit power" or the like which shows you it's just dodgy marketing speech. Nowhere do they put these 64-bit in a strong technical context i.e., explaining which components are actually 64-bit wide, the only thing which would matter here. So the point is, a label "64-bit", even w/ or w/o the "bit", on the box or wherever does not qualify it as relevant for this article, just like the 64 in C64. Nowadays, you could convince very few people with something like "64-bit" but back in those days, when consoles were referred to as "8-bit". "16-bit", the audience knowing the graphical difference between these, and 32-bit consoles where coming up, "64-bit" was deemed to be a strong selling point. Again, just like amounts of RAM where so important that they'd make it part of the name. --217.87.87.117 (talk) 15:09, 22 November 2007 (UTC)

"No, he doesn't. It is your assumption that the 64 in C64 refers to the RAM size. That's a fair assumption and likely true but there's no evidence that it's actually a fact." Completely nonfactual, its not his assumption, its a fact. Its also incorrect that there are no references, there are plenty. One for example: "The VIC-40 name lasted through most of the production design. However, marketing wanted to change the name to match the other computers in the Commodore lineup. They already had the P128, which was a personal computer with 128 kilobytes. They also had the B256, which was a business computer with 256 kilobytes. Now they had a consumer computer with 64 kilobytes, so naturally it became the C64. Most people just called it the Commodore 64." On The Edge: The Spectacular Rise and Fall of Commodore, Variant Press (2005), Pg. 248. Likewise, I wouldn't advise telling someone not to heed a warning from an admin, especially when the person he's warning has been warned for his conduct previously. --Marty Goldberg (talk) 17:58, 22 November 2007 (UTC)

In response to the C-64 argument: My point was that the C-64 specifically was named as such because of the memory - 64K was a lot of memory at the time, so it was a strong selling point for the machine. That doesn't mean that all numbers mean memory or data bandwidth, though - the TRS-80 wasn't named for either memory or data bandwidth. In many cases, the numbers were arbitrarily assigned, and still are (just look at the numbering systems for ATI and nVidia video cards). I wasn't making a blanket argument here, but was specifically addressing the C-64 argument. — KieferSkunk (talk) — 20:46, 22 November 2007 (UTC)

"I wouldn't advise telling someone not to heed a warning from an admin [...]" This looks somewhat out of place because I did nothing of the kind. --217.87.87.117 (talk) 19:13, 22 November 2007 (UTC)

Marty: The IP user is right, in this case - I didn't see any comment there that advised Theaveng to ignore me. He was addressing the content discussion in much the same way I was. Please ease off the trigger a little. Thanks. — KieferSkunk (talk) — 20:46, 22 November 2007 (UTC)

I was only just joking. And using that joke to make a point. Just because Atari called it "Jaguar 64" in their advertising, doesn't mean much. It's just a name like Commodore 64 and Nintendo 64 are just names. ----- I believe Computer marketing departments about as much as I believe my local car salesman (who claimed my Honda Insight Hybrid could run on all-electric; that was false; it never had that capability, even though the dealer's self-published brochure claimed it did). - Theaveng (talk) 15:42, 13 December 2007 (UTC)

I vote absolutely not. From the trace sizes, to the fact that most of the ICs aren't even surface mount, and the visual indications of very few layers in the PCB, it's impossible, as long as we're talking about the same device. photo of Atari Jaguar guts --Daniel Santos (talk) 05:15, 6 December 2007 (UTC)

Got the Atari Developer's Manual

As I suspected, it does not say what various Atari fans have been claiming. It doesn't say the Jaguar has 5 processors (it says "multiple"), nor that it is a 64-bit system (it says it "features 64 bit technology" which would be the blitter and object accelerator, not the whole system). The persons in support of claiming Jaguar has 5 processors and a 64-bit CPU have been running us in circles with claims... which the manual does not support. - Theaveng (talk) 15:33, 21 November 2007 (UTC)

MORE: In the Technical Overview, page 7, it states "the CPU, DSP, and blitter internal registers are 32 bits wide"..... not 64. Hmmm. - Theaveng (talk) 15:40, 21 November 2007 (UTC)

Can you point us to this manual, or at least where to get one? It's not that I don't believe you, but it would be beneficial to the article for this reference to be cited. In this case, the Atari Jaguar could be mentioned as "advertised as 64-bit, but in actuality only a small portion of the system uses 64-bit architecture", since this seems to be a common misconception about the system.

Theaveng: I don't really have an issue with your motives or your desire to keep things factual here, but you seem to be assuming bad faith quite a bit throughout this discussion, and other editors are accusing you of pushing POV in your edits as well. I would like to ask you to tone it down a bit and keep the discussion civil - there's no need to be as rude to others here as you have been lately - continuing to be as bitey as you have been may get you blocked for disruptive editing.

Same goes for others in this discussion - keep your cool, folks. Thanks. — KieferSkunk (talk) — 23:53, 21 November 2007 (UTC)

I've found: Technical Reference Manual, Tom and Jerry, by by Martin Brennan, Tim Dunn and John Mathieson, dated 28 February, 2001 Revision 8. It is a manual intended for programmers and it details the basic operations of the two processors in question (68000 is known not to be 64 bit). However it is not a hardware reference manual, which is what I believe to be the best reference for this manner. It can be found hosted here: http://www.hillsoftware.com/downloads/index.html Rilak (talk) 11:44, 22 November 2007 (UTC)

This Technical Reference shows indeed that even the GPU is a 32-bit unit. All its registers are at most 32-bit wide. The blitter has some 64-bit data registers and the only other component that is "64-bit" is the memory bus. --217.87.87.117 (talk) 17:07, 22 November 2007 (UTC)

Rilak - that's a later revision (by the actual designers of the Jaguar) of the Jaguar Software Reference Manual, and included in the zip file I linked to in the beginning of all this. The rest of the official Jaguar development documentation says to refer to the Jaguar Software Reference Manual for the reference on Jaguar hardware. --Marty Goldberg (talk) 18:04, 22 November 2007 (UTC)

Yes, I was aware of the link you have provided but unfortunately, downloading the file is not possible as it is too large. If you could provide a link to Jaguar Software Reference Manual, it would be appreciated. Rilak (talk) 18:46, 22 November 2007 (UTC)

Unfortunately, that's the only current link. I'll see about extracting the files and hosting them individually at atarihq.com so you can download it. --Marty Goldberg (talk) 18:48, 22 November 2007 (UTC)

The only apparent difference between these two files is the title and that the earlier "Software Reference Manual" is a scan instead of a textual document. It was simply renamed and covers some minor corrections. The file jag_v8.pdf as linked by Rilak which is also included inside softwarereference8.zip inside your linked ZIP file covers all relevant information about the hardware. The other documents are not interesting in this context. --217.87.87.117 (talk) 19:04, 22 November 2007 (UTC)

This all seems to support my earlier statement that it would be worth noting the Jaguar in this article as a machine that was advertised as 64-bit, but in actuality is not, by definition. — KieferSkunk (talk) — 20:46, 22 November 2007 (UTC)

That would be fine by me. I'm not strictly against a short mention of the Jaguar in this context but only because it's a well-known example and source of disputes. Otherwise a lot of lesser-known hardware might qualify, too. I do, however, think that it should be limited to such a brief note as in your example. In my opinion, the last article versions mentioning the Jaguar were far too verbose for this article. All details about the Jaguar (what's 64-bit and what isn't) should be explained in Atari Jaguar and not be repeated here. --217.87.87.117 (talk) 21:26, 22 November 2007 (UTC)

I absolutely agree. Thanks for your comments. :) — KieferSkunk (talk) — 22:23, 22 November 2007 (UTC)

RfC: Is Atari Jaguar 64-bit or not

Is the Atari Jaguar 64-bit or not?

I'd say No. It is a marketing gimmick like Saga's "blast processing" or the Turbo Graphics 16, which was an 8 bit system. Algr (talk) 17:03, 22 November 2007 (UTC)

I'd refer to the discussion above - it seems that there's enough conclusive evidence to show that the Jaguar is not properly a 64-bit machine, at least by any accepted definition being used in this article. And as such, I believe any further discussion about the nature of the Jaguar should be moved to Talk:Atari Jaguar. — KieferSkunk (talk) — 22:27, 22 November 2007 (UTC)

As A coder for the Jaguar since 1993, I cant tell you without a doubt, it is a 64 bit system. You cannot use the main procesor as the determinig factor anymore...that went out as soon as they put nmore than one bus size on the same console. The PC is a very differnet architecture in that is ia a 32 bit processor that can talk to other bussses. The JAguar 64 bit is 64 bit throught out the entire system and the MMU is responsible for the size it need to read. Everything alse about the system is gear toward movemnt and math of 64 bit values. —Preceding unsigned comment added by 68.44.65.100 (talk) 15:26, 1 January 2008 (UTC)

In response I will quote someone else, because I agree with 99% of what they said: "This Technical Reference shows indeed that even the GPU is a 32-bit unit. All its registers are at most 32-bit wide. [A few select operations of] the blitter has some 64-bit data registers, and the only other component that is "64-bit" is the memory bus. --217.87.87.117 (talk) 17:07, 22 November 2007 (UTC)" ----

IMHO, the Atari Jaguar definitely belongs in this article, simply because so many people remember it's ad campaign. Even if there is nothing truly 64-bit about it, the machine is still a useful example of what '64-bit' does and doesn't mean. It is also a service to the reader to address the existence of widespread misinformation. Algr (talk) 23:14, 6 February 2008 (UTC)

To add the Jaguar, and then say "this is an example of a system that is not 64 bit" would be original research. OR is not allowed on wikipedia. ----- Also if we're going to be using examples, I'd rather use the Nintendo 64, since (1) it's well, well known having sold 30 million units and (2) it truly is 64-bit CPU, but only internally. (Externally it is 32-bit.) N64 is a good explanative example of how "bitness" can be variable depending upon what you are measuring, and virtually everyone knows what an N64 is. Theaveng (talk) 14:17, 8 February 2008 (UTC)

If questioning the ad campaign is original research, then we would have to uncritically state that the Jaguar IS 64 bit. There were sources who questioned the Jaguar's claim even before it shipped Even "Atari Age" questions it:

http://www.atariage.com/Jaguar/history.html

http://books.google.com/books?id=PnPRd6QwvbQC&pg=PA47&lpg=PA47&dq=atari+jaguar+68000+64+bit&source=web&ots=X5P3dtGUQS&sig=Ot076me2wOOaFs7VHkKxFwvB4og&hl=en

Algr (talk) 16:10, 14 March 2008 (UTC)

Does a shrink of an existing 64-bit processor line belong in "64-bit processor timeline"?

The introduction of the first 64-bit processor for a given instruction set architecture clearly belongs there, and I'd see the removal of the last 32-bit general purpose processor (leaving only embedded processors) or the removal of the last 32-bit processor for a given instruction set architecture as noteworthy, but I'm not sure that, for example, the replacement of 65nm Core 2 64-bit processors with 45nm Core 2 64-bit processors is particularly relevant to 64-bitness. What events belong in that timeline, and what events don't belong there? Guy Harris (talk) 18:56, 16 January 2008 (UTC)

I don't believe the timeline is for listing every single 64 bit processor made, only those that are important, such as the first processor implementing a new 64 bit architecture, eg. PA-RISC 2.0 and PA-8000. I think the 45 nm COre 2 entry should be removed, since its not new in regards to bitness. Rilak (talk) 10:14, 17 January 2008 (UTC)

PPC 620?

As the above comment suggests, "the first processor implementing a new 64 bit architecture" seems like a worthy criterion for inclusion in the timeline. So where's the PPC 620, the first 64-bit PPC? (Around 1994, I believe.) —Preceding unsigned comment added by 69.71.164.107 (talk) 09:38, 24 January 2008 (UTC)

The PowerPC 620 actually came out sometime during 1997 and was only avaliable for a very short time in one machine, I believe. I think I'll just wait for more comments before doing anything. Rilak (talk) 05:39, 25 January 2008 (UTC)

Decimal/binary notation

That IP edit (and this one) was me; I'm having trouble staying logged in. In any case, regarding the reversion back to binary notation: Decimal notation is unacceptably vague in this article. If it must be used, then it needs to be defined as Kilo- = 2¹⁰, etc. somewhere in the article. That's a bit silly, hence the binary notation. See Wikipedia:Manual_of_Style_(dates_and_numbers)#Binary_prefixes, the bit involving certainty. In the context of this article, the units unequivocally refer to units with binary prefixes. —BorgHunter (talk) 22:44, 3 March 2008 (UTC)

From MOSNUM: "There is no consensus to use the newer IEC-recommended prefixes [This means GiB/MiB etc] in Wikipedia articles to represent binary units." and "When in doubt, stay with established usage in the article, and follow the lead of the first major contributor.". Looking at old version it uses GB or even [7]. If you really want to make the units "less vague" then I'd prefer you disambiguate by stating the number of bytes exactly, such as "256 KB (256×2¹⁰bytes)". Disambiguation does not mean replacing all units with something else, which is what your edit did. It does mean placing something in brackets afterwards and not using those brackets too often. The JEDEC defines these units in the binary sense for computer memory, so they are not "unacceptably vague". Fnag aton 22:55, 3 March 2008 (UTC)

I don't understand why that's necessary, though. I know common practice is to leave units as the article originally had them, but in the spirit of IAR and whatnot, is there a good reason to keep using decimal prefixes disambiguated in parentheses, when a precise and totally unambiguous alternative exists? —BorgHunter (talk) 02:24, 4 March 2008 (UTC)

The thing is KB/MB/GB are not only decimal prefxies becuase yhey are also defined by the JEDEC as binary prefixes, i.e. powers of two. The reasons are stated in the guideline, there is no consensus to use the IEC -bi prefixes. The problem with the -bi prefixes is that they are very rarely used in the real world, they are not accepted use, which means Wikipedia is not the place to push one standard over another standard. The outcome of this problem is to follow the consensus in the real world which means use the units found in reliable sources relevant to the subject. If you read things like memory datasheets they mostly use KB/MB/GB etc, I've not seen even one datasheet from a manufacturer that shows -bi use. Fnag aton 08:21, 4 March 2008 (UTC)

Quite true about KB/MB/GB being more commonly used. But then in fine print somewhere you get something like this: "the prefix KB in this document refers to 1024 bytes..." And this is not recent practice, I have DECchip 21064 manuals stating this in their manual of style section. I think it would be quite appropriate if we used something more precise than MB/GB, since the exact value of these units depends on the context (RAM, hard drive, flash memory, whatever) and can create confusion. If you state something to be exactly this, then there is no confusion. Rilak (talk) 08:53, 4 March 2008 (UTC)

Perhaps we should abandon the silliness of KB/KiB and MB/MiB and just use 2³² to express 4,294,967,296 bytes, which is the maximum address size of a 32-bit chip... eg. Unlike 32-bit CPUs, a 64-bit CPU can address more than 2³² bytes of memory. Or is this too confusing for most people? Rilak (talk) 04:29, 4 March 2008 (UTC)

The general thought on prefixes in general is that they make the number less cumbersome, but I have no real objection to using the number of bytes and abandoning all prefixes. —BorgHunter (talk) 04:48, 4 March 2008 (UTC)

In this case, the use prefixes seems to be making things more complicated due to unnecessary reverts. After a quick read of the article, I do not believe that there are any values that cannot be expressed by 2^x, so I might replace the prefixes. This method is already used in the article, so I don't expect to be any opposition to its use. It should be noted that this method of expressing the maximum address ranges is pretty common, at least with microprocessor datasheets and technical journals (DEC, HP, IBM). I'll leave this for a few hours to await more comments before editing though. Rilak (talk) 05:12, 4 March 2008 (UTC)

I don't like the SI binary prefixes, but I'd rather be precise than ambiguous. I'd rather spell out "4 gibibytes (4.3 gigabytes)" rather than leave the reader confused. By providing both units, the reader knows exactly what they just read. It's clear. ---- Theaveng (talk) 11:53, 4 March 2008 (UTC)

Putting gigabytes in brackets would be changing the units used in the article which is against MOSNUM. Gigabytes (GB) etc are the units used so according to MOSNUM they remain in the article as the primary units. Using "4.3 gigabytes" is also obviously wrong since gigabytes in this context are obviously powers of two, as defined by the JEDEC. Using GB/gigabyte with disambiguation in brackets using power notation (2³²) would be acceptable. Fnag aton 12:02, 4 March 2008 (UTC)

Why the strict adherence to MOSNUM? It's a style guideline, not something that must never, ever be broken. If giga/mega/etc. in this article is broken or doesn't work all that well, then it should be fixed, no matter what MOSNUM says. That said, Theaveng's suggestion is still ambiguous; I favor Rilak's suggestion of removing all prefixes completely if there's major opposition to binary prefixes. —BorgHunter (talk) 17:14, 4 March 2008 (UTC)

Because the -bi prefixes are not used by the majority of reliable sources relevant to the article and there is no consensus to use those prefixes, i.e. using -bi prefixes makes the article inconsistent with the relevant reliable sources. The article is also not "broken" by using the prefixes it has now, it is obvious exactly what the numbers mean and using something like "1 GB (2³⁰ bytes)" makes it perfectly crystal clear. Fnag aton 17:26, 4 March 2008 (UTC)

Processors should be seprated from OSes

This article puts too much emphasis on processor support of 64-bit without mentioning enough about OS and development tool support. For example there is no mention that Mac OS 10.5 (Leopard) is a full 64-bit OS in all its forms while Windows Vista Starter is still crippled to 32-bit support and Home Basic/Home Premium/ Business don't come as 64-bit installs by default (64-bit install must be ordered separately) [8]. Also there is no mention that Windows XP Professional x64 Edition does not have the full level of support that regular Windows XP Professional has. All that is mentioned is that XP Pro 64 was released at a particular date. Another example is that Mac OS X 10.4 (Tiger) supported 64-bit addressing, but none of the Cocoa and Carbon GUI application frameworks libraries were updated.[9] —Preceding unsigned comment added by 63.175.18.130 (talk) 00:30, 27 March 2008 (UTC)

Trimmed the timeline

I trimmed the timeline down to what IMO are the "firsts". The dual-core processor releases in particular have no business on this list. I'm undecided about leaving the Core 2 reference in there - I only left it in because the Core 2 wasn't a retrofit design like the EM64T P4's.

AntiStatic (talk) 09:19, 22 June 2008 (UTC)

I restored the entries for the PA-8000 and POWER3. The PA-8000 was the first PA-RISC processor to implement the PA-RISC 2.0 ISA, the first 64-bit revision of the PA-RISC ISA, surely worthy of mentioning. I also restored the the POWER3, as that was the first 64-bit PowerPC chip that was commercially avaiable (unless you count the PowerPC 620). Rilak (talk) 09:53, 22 June 2008 (UTC)

Surely the RS64 was the first production 64-bit POWER/PowerPC processor, predating POWER3 by about a year (1997 vs. 1998)? See here. Letdorf (talk) 10:24, 23 June 2008 (UTC).

I think the RS64 was based on the PowerPC AS ISA, which was completely incompatible with PowerPC ISA. Anyways, the A10 and A30 were the first microprocessors to implement the PowerPC AS ISA, and they predate the RS64 by two years as they were released in 1995. Rilak (talk) 11:49, 23 June 2008 (UTC)

From what I've read the RS64 implemented both the 64-bit AS/400 "Amazon" ( PowerPC-AS) architecture and 32- and 64-bit PowerPC architectures, and was used in both AS/400s and RS/6000s. I guess the A10/A30 should be mentioned as well if they were the first 64-bit AS/400 processors. BTW, I've found more information in this article. Letdorf (talk) 15:50, 24 June 2008 (UTC).

OK, I'll add the RS64 to the list, but does that mean we have to remove POWER3 from it? The RS64 implemented 64-bit PowerPC in 1997, before the POWER3, which was released in 1998. Rilak (talk) 08:54, 25 June 2008 (UTC)

I've got no idea why I deleted the PA-8000 in the first place ... I still use one of the things. I claim lack of coffee. AntiStatic (talk) 10:55, 24 June 2008 (UTC)