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.
well, 64-bit linux systems have been available for quite a while now. since the kernel and practically the entire application codebase are available to the public as source code, the transition has been quite painless for end-users. 32-bit emulation libraries have ensured that 32-bit binary programs work almost flawlessly.
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.
64-bit Linux has been around for about a decade, since the initial DEC Alpha port. There are at least four 64-bit architectures with Linux support at this point, and it's well tested and debugged.
As for the Windows side, the lessons of the 16->32 conversion were not wasted, abstract types created for that conversion are still in use, and will certainly make the new transition much easier. There will be some bugs that will need to be shaken out, but it's unlikely to be the sort of major effort it was last time.
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.
Wow, that takes me back...the days of message cracking, porttool, and NT 3.1
Thanks for the walk down memory lane.
Nothing is inexplicable; only unexplained -Tom Baker, Doctor Who
This one is sure to hit it.
Been running a 64 bit dual proc AMD Linux for about a year. Been running a 64 bit AMD Win 2K3 Server for about 5 months. Been running a 64 bit Sparc Linux for about 2 years (personally - all of these were out long before I got to them)
Here is the big difference. When you remember the 16-32 bit port - most of the problems I saw were to memory protection, and dealing with ring transitions. We have all ready solved these problems, so the port to 64 bits is pretty painless.
I have mod points and I am not afraid to use them
Porting from 16-bit Windows applications to 32-bit Windows is sort of comparible to the problems you face running Windows applications under Linux using WINE. In both cases, you're going to a new OS, and relying on a compatibility layer.
A 32-bit Windows application running under 64-bit Windows just won't face these issues. There will be some 64-bit features it won't be able to uses, that's all.
Windows users may have a problem: Most installers are still 16 bit. I installed XP64 on my Athlon64 box and couldn't do much of anything.
Note: I'm a gamer.
Not a Twitter sockpuppet... but I wish I was.
I had my asm class in college on the MC68000, and remember that it had 16-bit control and data buses (with 32-bit registers!) and a 24-bit address bus. Since 2^16 can only address 64K, and 4GB would have been way overkill in those days, I guess 24 bits was somehow logical.
And I too remember plenty of warning for getting "32 bit clean".
Attention zealots and haters: 00100 00100
without knowing the form the x99986 processor will take, to, while coding for 64bit, to leave room for 128 bit. (I have no idea of the practicality myself)
got a program that will still be around in five years? telnet client? something?
great... whilst coding it for 64 bit, leave room for another bit, so in five years, you can 'turn it on' and be that much ahead of the game.
every day http://en.wikipedia.org/wiki/Special:Random
This is just stupid. We exhausted the 16-bit address space in the era of the Osborne and Apple Poo. Ten years later we experienced a painful "transition" to 32 bits (after completely exhausting kludge space). The present situation is that high end machines can make good use of a 64-bit address space in kernel, but 99.9% of userland processes could remain 32-bit for a long time yet. The rare exceptions, such as database servers, those have been 64-bit clean since before the Alpha was first invented.
Sure, let's compare a transition that took place ten years after the pain was universal to a transition that took place quietly ten years before most people realized that a 32-bit virtual address space could be exhausted with far less physical memory as a result of mechanisms such as nmap.
Java is supposed to be platform independent, but the implicit assumption has always been a 32-bit platform of one sort or another. Yes, Java can run on a 64-bit processor, but the int is still 32 bits unless you want to change the behavior of an awful lot of Java code.
So will there be two Java's or are they going to come up with some kind of clever 64-bit Java extension or what?
Oh, and as to the comments that it takes a shockingly big Word document to bust a 32 bit address space, the big address space is not for Word, it is for video. The change to 32 bits and faster processors made CD-quality audio pretty much universal on desktop computers, but HD-quality video is not there yet. Sure you can stream from files or segment memory, but 4 Gig is still constraining with regard to high definition video files being handled in linear address space.
Who lets these crackheads post stories? Linux has been running native 64-bit on several platforms for years, and years, and years. Hell even in the x86 world, I've got ~9,000 Opteron CPUs chugging under the power of Linux in 64-bit mode at work, and they're just trashy lease boxes.
11*43+456^2
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
How is that different that the current 32 bit mode? If I remember correctly (and google still serves me right ;) all Linux binaries start at 0x08048000. Windows does the same, just a different address. What exactly does the 64 bit add other than larger word sizes and a few extra registers?
If I remember my history right, it was the 286 that added this mode. Granted the addressing was in 24 bit but it tossed out haveing to split up your memory address across 2 pointer registers ( I still curse those damn data segments, when I'm drunk enough).
Linux is really boring from an os standpoint. Now Plan 9......
You may have been running 64 bit linux for a little while on the x86 but you strike me as a guy never seen the joys of real mode vs. protected mode. You should Google up some of the angst filled rants from programmers who had to deal with it back in the day.
Some of that old code is just crazy.
We got it so easy these days almost makes me feel lazy.
Linux is really boring from an os standpoint. Now Plan 9......
My primary system (LFS) has been 64-bit for quite some time. Pretty much no shocks, either.
The only things not working well for me in 64-bit are:
I even have 64-bit hardware accelerated video drivers (NVidia).
Now, 64-bit Windows is another story. I think it will be quite some time before everyone's apps are 64-bit - since no one can recompile the code and fix the various pointer problems.
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
My SGI Indigo 2 r10k is a 64-bit MIPS proc running at 200mhz with 576 megs of RAM, running IRIX.
:|
The indigo2 was released in 1993.
I do believe mine (the purple, 64-bit beast) came along in 95 or 96.
UNIX and by logical extension freenix has always been years - if not decades - ahead of gear that Joe User can buy on his salary. Anybody who thinks freenix has any sort of "catching up" or "adapting" to do to achieve 64-bit perfomance is obviously highly ignorant of computing history.
I upgraded to an Asus A8V-Deluxe with an AMD64-3000 processor last week. .iso and to find a good amd64 mirror, but it was frankly boring in how easily it installed. It's just another Debian install nothing special, and because it's Debian you only need to install it once.
The AMD64 / true64 port of debian is not an official part of Debian (waiting until after the release to add it).
It took a little googling to find an install
As for hardware, everything worked out of the box without fooling around including the USB, the onboard gig-ethernet, the onboard sound, etc. I haven't tried the firewire or the SATA but I assume it will work.
As for software, everything in i386 Debian seems to be in amd64 / true64 Debian with the exception of qemu and the openoffice.org suite. I haven't bothered to set up a chroot environment but they say that'll allow that stuff to work.
It's just another open source success story, and theres so many of those, that this one isn't even noteworthy.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger