Slashdot Mirror
32-bit to 64-bit - Obsolesence Pains Again?
robotsrule asks: "Having been in the computer industry a while I distinctly remember the pain of making the 16-bit to 32-bit transition, when Windows made the change to 32-bit support. Any developer who remember the joys of thunking and other kludges that were meant to help code conversions also remembers the arcane marathon debug sessions too. I have not been keeping up with the latest Microsoft Longhorn technical news, or the plans that the Linux community has for 64-bit platform support. Does anyone out there have a reliable prediction for the amount of system shock we are facing when either Longhorn or 64-bit Linux comes out? Will I lose all my favorite 32-bit development tools again as I watch the backward compatibility support dry up as the 64-bit O/S platforms are adopted? Or are the O/S manufacturers making happy noises about long-term support for existing development languages and tools?"
The happy noises heard are the coins falling into their pockets.
AMd has been good to us lately. i think they'll continue to 'do the right thing'. Maybe they're the Google of hardware.
Mike
Yep, I never spell check.
More incorrect spellings can be found he
My latest gentoo install is 64 bit, built from the ground up. works great for the most part. there was no lilo that i saw, but I use grub anyways. other then that i'm not missing anything. I've known people that've ran 64 bit in different distros for a couple months now, and they're all quite happy with it.
when [...] 64-bit Linux comes out
64 bit Linux came out about a decade ago, when it was ported to the Alpha (and, unlike Windows NT for Alpha, it was a true 64 bit port).
amount of system shock we are facing when either Longhorn or 64-bit Linux comes out?
Umm.. no offense, but where have you been? 64-bit linux has been out for a LONG time. Some platforms have been 64-bit kernelspace (sparc64, ppc64, alpha, amd64) and have had 64-bit userspace (alpha) while others have had a mixed 32-bit and 64-bit userspace (sparc, mips, ppc, amd64).
Most open source apps are already ported. Are you really doing things at a low enough level where you have to worry about thunking?? You might have bigger problems then.
-molo
Using your sig line to advertise for friends is lame.
True, a large part of that was due to MS-DOS being the platform of choice, but the speed with which you need to adapt to the 64-bit environment will be made up for by the relative ease of conversion. We're relatively insulated from the word size of the system, except for the size of 'int' in C, and we won't have to deal with memory managers or extenders -- that's all up to the OS.
Just keep in mind while you program to be flexible and avoid tying yourself to any OS particulars in an unnecessary way. It's a bump in the road, but nowhere near as bad as it used to be.
I expect to see 32-bit support in development tools for years yet. Microsoft's window of support seems to be five or more years for operating systems so you've got at least that much time.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
Huh!? Sure it did. You couldn't run 32 bit code on a 286. In practice, by the time 32 bit became effectively mandatory (Win95), the sheer horsepower requirements pushed an upgrade more strongly than word size. It'll likely be the same this time around.
The 16 to 32-bit PC transition didn't require you to go out and buy new hardware. Years from now, we might all be forced to use a true 64bit AMD to run anything.
You mean I won't be able to run new software on my 286 any more? That BLOWS, man!
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
> the int is still 32 bits
Defined that way by the language standard and will always be that way on any platform past, present, and future. That's why it's platform-neutral, because you don't have to deal with ridiculous low-level issues like the size of standard datatypes. All primitive types are fixed by the language standard. These sizes do not change from one machine architecture to another (as do in most other languages). This is one of the key features of the language that makes Java so portable.
Need more than 2,147,483,647? Try long -- 9,223,372,036,854,775,807. Still not big enough? java.math.BigInteger is arbitrary precision.
Although programming in Java has lost some of its charm for me, I never ever again want to have to program in a language where I don't know from one platform to the next whether or not a particular bit of arithmetic will overflow.
64-bit mode on AMD abandons the idea of segments.
You don't need them to get around the 4GB limit (no need for PAE), and no operating system was using segment protection of memory anyway; relying solely on page protection flags.
Everything in 64-bit mode ends up in a known, fixed location of memory (like on old Macs)
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Planning for 128 bits of address space is insane.
Don't let you be fooled by the fact that 16->32, and 32->64 seems similar and infer that 64->128 is the same.
First the exponential increase in performance/memory size gives you a linear increase in bit count. Doubling the bit count is a very rare event.
Second, hitting a limit on 64 bits would mean 4 billion times 4 billion bytes.
Think about it. 73 millions of 250 gigabytes hard drive *per* application.
All the movies from imdb.com, in DVD format, in memory. 4500 times.
An DiVX of your whole life. 43 thousands times.