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?"

Comments

Happy noises

[bluelip]

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

Thunking!

[Wabbit Wabbit]

Wow, that takes me back...the days of message cracking, porttool, and NT 3.1

Thanks for the walk down memory lane.

Re:64-bit linux

[jnik]

Hmm... but this is different. The 16 to 32-bit PC transition didn't require you to go out and buy new hardware.

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.

Re:OK - is this the most stupid AskSlashdot today

[WhatAmIDoingHere]

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.

Re:16bit huh? 24bit yes

[Bill Dog]

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".

easy to quantify

[epine]

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.

Re:easy to quantify

[MemoryDragon]

The main problem with the 16-32 bit transition was the dreaded segmentation, the code for this had to be moved into a flat mem model (the first thing the compiler people did was to expand one segment to full mem size and get rid of the segmentation at all, which Intel wanted to carry over into the 32 bit world - speaking of stubborn and shortsighted) and that lots of code was pure assembler, the other problem was that lots of programmers used the good ole trick of number boundary overloading to zero values or to push them into a negative domain, which of course only works as long as the bytesize of your registers do not change, which happened back then. All these were tricks to save clock cycles and mem. I dont expect that the move to 64 bit will be as bumpy and 64bit linux has shown that indeed it is not.

Oh yeah, what about Java?

[Latent Heat]

Linux can be happily 64 bit, and Windows may attempt to be 64 bit, but what are people going to do about Java?

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.

It's a valid question

[jojo tdfb]

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.

Re:It's a valid question

[DarkDust]

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.

Note: my memory may serve me wrong, the following could contain errors.

The difference of real and protected mode that was alien to the developers wasn't so much about 16 or 32 bit but about the way memory was addressed. In real mode memory is addressed with a 24 bit hack and people where used to that. Additionally, they didn't have to care about memory protection and setting stuff up, real mode is just plain simple to use.

By contrast, the transition from 32 bit (protected mode) to 64 bit is very soft, as far as I remember there are a few new opcodes and a few new registers, but the hard stuff like addressing memory hasn't changed much to my knowledge... then again maybe someone who actually knows some AMD64 assembler could shed some light here ?

Shock? I think not.

[Golthur]

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:

• Flash - Yes, I know I can use a 32-bit compiled browser and install 32-bit Flash, but I don't want to :)
• Wine - I've compiled it 32-bit, and everything works except sound :(
• OpenOffice - but I'm running the 32-bit binary with no problems.

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.

Kids these days...

[solios]

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. :|

Installed AMD64 Debian last week

[vlm]

I upgraded to an Asus A8V-Deluxe with an AMD64-3000 processor last week.
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 .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.

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.