I don't know, I was never a huge fan of either frederickson (1.0) or fredrickson (2.0 or ff)... but fredrickson's mom is another story!

We want more poems!

-----------------------------------------
Of course I could be wrong... but really, what are the chances of that happening twice?

...this is very strange in fact, i looked over this so called fredrickson, what in the hell is this. i feel violated and jeesus CHRSIt WHO sthe hell si this person to take my name and defile it oh my god i am so angry...

First off, welcome back. Did you spend your entire time away in Hungary?

You should be angry. This joker has defiled your kooky name!

Now I know how George Foreman feels!

-TPFKAS2S
http://www.braglio.org
How many toes does a fish have?
How many wings on a cow? I wonder, yep. I wonder!

Actually your "fredster 2.0" is really mother of "fredster 2.0" so indeed you are wrong!


Dan
Intel 486SX, Trident video, 8MB RAM, 14" Generic Monitor, 100 MB HDD, Windows 3.11

thanks for (kinda) clearing that up nin

He started out as an annoying troll (talking about fredrickson, frederickson, whoever) now he's actually funny sometimes

nin: enjoy your vacation and don't pick up any little children to take home with you

A quick recap for those just tuning in:

1. fredster 1.0 comes back from the dead! (GASP!)

2. fredster 1.0 finds his name soiled by fredster 2.0! (GASP again!)

3. fredster 1.0 and fredster 2.0 are now indistinguishable from each others posts, and will now dual to the death.

I would say "TWO MEN ENTER, ONE MAN LEAVES!!!" but I think they both might be small children.




Film at 11!!!


edit: spelling, dammit!

This comment was edited on Feb 28, 10:33.

how dare you i am fredicksons mother and you are a rude little mosnter dont you dare talk to me like that ever again you are disgusting and i blame you for the death of my son you are steakling MY NAme and i hope you get eating be termites starting with your crotch

this is very strange in fact, i looked over this so called fredrickson, what in the hell is this. i feel violated and jeesus CHRSIt WHO sthe hell si this person to take my name and defile it oh my god i am so angry i went to on a trip for a few months and this is the rftreatemnt i get oh my goddddd its a sad state off affairs in the usa i am back for onl;y a moment and already i am reminded of the terror and scheming of american boys i can assure you that i will fix u all and demand a better day for u and me we are the world dont you never forget its a result of this american imperialism and these americans are very bloodthirsty you can asee that in comand and conquered you are murdering innocent chinese are they next on axis of evil its sad sad sad and i am mad
This comment was edited on Feb 27, 22:00.

who.
the.
hell.
are.
you?

To the person who suggested that backwards compatibility is not desired. In the business world, especially in the tough economic market we are in, businesses do not have the resources to go out and change all of their software. Additionally, you get a chicken and egg thing going. Developers don't want to create too much content because the hardware isn't in place and the market is small. While at the same time, users don't want to invest in hardware that isn't widely supported by software. Its a catch-22.

However, by building in backwards compatibility, AMD will actually SPEED up the process of 64 bit migration by giving end users the comfort factor of having the ability to run both new 64 bit applications as well as current applications. This in turn will give software developers a larger market of 64 bit computers and therefore will naturally develop software to support.

AMD will lead the 64 bit migration by using this approach.

First, to the person who posted about the Barton. The Barton has a much larger cache.

Regarding the mention of a 2GB limitation in 32 bit computing, the limitation is actually 4GB. In 64 bit, the theoretical limitation is 2TB!

Having just had a good look through all of the posts previous to mine, I can't see anywhere that the 2Gb RAM limit is mentioned... I wasn't suggesting that you specifically were missing the point, but a lot of people seem to be doing so

No, I wasn't missing the point...as someone who does quite some 3d work (but from an engineering point of view) I know that, and iirc that was one of the first points of the first posts here...I was just giving more arguments instead of going over stale ones.

Ah... I laughed so hard I leaked from every orifice.

I don't mean to be annoying, but I sincerely believe that everyone here is totally missing the point of what Sweeney's saying.

64-bit computing is phenomenally important from the point of 64-bit addressing. 32-bit Addressed PCs are limited to 2Gb of RAM, purely and simply. Intel have what they call an "address windowing extension" which I don't claim to fully understand, but what I can see is that it allows access to up to 4Gb of RAM total, but only 2Gb of it may be accessed by any given process. This is the limit that I believe Sweeney's talking about running into. Next-gen content creation tools are going to need more than 2Gb of RAM. The current set need over 512Mb to run comfortably, and preferably 1Gb. That's where the main problems lie. As soon as you're using 64-bit address spaces, 64-bit data and such are a moot point. Of course, most content-creation systems run at high-precision for floating-point systems, to ensure the best content is produced. High-precision on PCs means 64-bit, which of course a current 32-bit CPU needs to use multiple registers for. All in all, if a 64-bit CPU is architected correctly, there'll be gains for everyone.

...one thing about backwards compatibility: the price. Sure, your user experience won't change, but your wallet will sure feel the difference! Do you really think all those companies will offer their newly recompiled (and assembly-rewritten!) 64-bit software for free? No way...minimum would be p&p, more likely you'll have to pay for the 64-bit upgrade and in some cases you'll have to buy it like it was new software.

That, plus the fact that you can use 32 and 64 bit software at the same time, is why AMD has gotten it right with their 64-x86 architecture.

As to breaking backwards compatibility, I don't really think the users/consumers would care, or that their opinion would even matter, if all the software companies were willing to quickly and dilligently provide recompiled builds of their applications for the new architecture. I mean, would most users even really know the difference? Most people who use computers don't understand anything about the underlying hardware, they just want to know their software works correctly. If a new CPU architecture came out that broke backwards compatibility (like the Itanium, maybe), and developers were on the ball and readily made versions of their software compiled for the new architecture available, your average end-user wouldn't even know the difference. A well written VM to emulate the old architecture (as there is a x86 emulator for Itanium users) would make up for the few developers that didn't update their software.

The problem here is the same as with games not supporting modern video card capabilities -- a game developer doesn't want to make a game require a certain hardware component until there are a lot of people with that hardware; but people don't want to buy the hardware until there are a lot of games that utilize it. In the same way, Intel and AMD don't want to push a backwards incompatible architecture until there is committed software support for the new architecture; but, software developers don't want to go through the hassle of supporting a new architecture that very few people have. There's really no good solution here, so we just keep extending the existing architecture, flawed though it may be.

Ultimately, I think Intel has the right idea with the Itanium: first, get the architecture in place with the server market. Then, the corporate/business market will follow once the price drops a bit and there is better software support. Then your average end/home users will follow.

This comment was edited on Feb 27, 05:35.

Any improvement, besides a lot more zeroes? You did twice the work, and got the same result. You've "wasted" the extra work.

As the previous poster stated, the site that #14 obtained this information from has no idea what they're talking about. Oddly enough, fredrickson's mom said it correctly (after the poem) when she mentioned that if you design a 64-bit hardware operations, you'd optimize it so it was fast and efficient. It will generally not take longer than the 32-bit operation, especially on a modern computer system where they have so many transistors they hardly know what to do with them all.

You can verify this information yourself. Go to intel.com and download the instruction-set documentation for the 64-bit processor and for their 32-bit processors. You'll find a table that lists the instruction name, how many bytes it is, and how many clock cycles it takes. The only reason why there'd be any difference is because you may have a 32-bit system bus and so to fill a 64-bit register you'd have to read from memory twice.

Anyway, I'm actually all for getting rid of backwards compatability. Just give me a virtual machine to run my legacy 32-bit apps and I'll be quite happy. Modern computing has been plagued by backwards-compatibility requirements and Intel has been stuck with fairly awful architecture because of it. By scrapping backwards compatability every now and then, we'll be able to actually make leaps in computing instead of steps. Of course, it'll be a major pain for us application users, and I bet there are more people who'd be upset with breaking backwards compatability than people like me.

#14,

Yea, so that's all fine and dandy, but the people at overclockers.com are completely talking out their ass and/or have no knowledge about how programming actually works. To use their example of multiplying 2x2, moving to 64-bit actually makes the process of multiplication much more efficient (in a programming sense). Here's the technical explanation:

On a 32-bit x86 based CPU, you have only four 32-bit (4 byte) registers to work with freely: EAX, EBX, ECX, EDX. There are more 32-bit registers than that, but they have specialized purposes, so I wont get into those. Anyway, in general, the processing taking place in a given program only has those 16 bytes on the CPU for free use, any other data has to go on the stack (in memory). Putting data on the stack, then taking it off later, is extremely slow compared to just working with the data in CPU registers. So, in a complex routine/algorithm working with lots of variables, you keep the most commonly accessed data in CPU registers (so as not to act as a bottleneck) and the rest of the data on the stack. To reiterate, because putting data on the stack is so much slower than working with data in registers, you want to keep as much data (and/or the most commonly referenced data) in registers as possible, and use the stack as little as possible.

To get to the multiplication example, the assembler instruction for multiplication is MUL. MUL returns a 64-bit result, the upper 32 bits of which are put in EDX, the lower 32 bits in EAX. So, just to multiply 2x2 on a 32-bit processor, you have to preserve the data in EAX and EDX (assuming you need it later) by taking their existing contents and putting them on the stack (or in different registers, which are most likely already in use, so you're stuck with the stack), then retreiving that data off the stack later. As we have already established, this is slow. So, with 2x2, even though we know beforehand that we won't need EDX (because 2x2 = 4, with is less than the maximim value stored in 32-bits, 4294967296), we still have to slow things down (access the stack) to preserve the data in EDX before doing the multiplication.

Their example of multiplying 2x2 in binary is nice and all, but it's irrelevant because in reality, multiplication already returns a 64-bit result (even on 32-bit processors). But if this were a 64-bit CPU, that 64-bit result could have been stored on one register instead of two, thus there may not have been any need to access the stack, which thus speeds up the process. So, you see, even the simple 2x2 is faster on a 64-bit CPU, and certainly nothing is being "wasted". Yes, this is an oversimplification, but it illistrates the point. Nothing against overclockers.com, but they obviously don't know what the hell they're talking about, in a practical sense.

Are they going to re-code the whole game to take advantage of the extra 32 bits?

Actually, no re-coding is required (except any code that was written in assembler). All that is required is to recompile the code with a compiler that supports the new architecture (64-bit x86). Not too difficult or time-consuming there, so yea, why wouldn't Epic do it?

This comment was edited on Feb 27, 04:41.

in other words- shortsighted individuals.

Oh, and there is one more type of person who claims we don't need 64-bit. Corporations who don't have a viable competitor to AMD's Hammer. That is a)Backward compatible b) efficient and c)affordable.

That company right now seems to be Intel. Its funny though, because, one day Intel is going to have to market 64 bit chips to more people, and what are they going to say then? They will basically have to negate every arguement and piece of Fud they have spat out so far [which is pretty easy to see through, if you have any know-how and a shred of objectivity]

The list goes on and on. At the end of the day though, we will only know when the Hammer is released whether it is a success or not. But saying that it flat out ***isn't needed*** before we're even at that point is pretty closed minded. It displays a lot of ignorance, and either someone was spoon fed that notion by intel, or simply has a naieve view of the world's demand for computer power.

its funny, because the same type of people who are saying that we dont need 64 bit now, are the same type of people who said we didnt need 32-bit color a few years ago. And the same people who said we didnt need hardware transform and lighting.