32-bit to 64-bit - Obsolesence Pains Again? 184
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?"
Happy noises (Score:4, Interesting)
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
Re:Happy noises (Score:2)
In other news... there IS already Fedora for 64-bit. I haven't tried it yet, but as soon as I get my dual Opteron system goin
64 bit linux :-)? (Score:5, Insightful)
Re:64 bit linux :-)? (Score:2, Informative)
I have the same setup, but I cannot say that I'm not missing anything. Although almost everything I use is open source and can therefore be ported and, for the most part, has been ported, there are a few closed programs whose binaries haven't been ported that I miss a little bit.
Re:64 bit linux :-)? (Score:2, Insightful)
Re:64 bit linux :-)? (Score:5, Informative)
Re:64 bit linux :-)? (Score:2, Informative)
* dev-java/blackdown-jre
Latest version available: 1.4.2.01-r1
Latest version installed: [ Not Installed ]
Size of downloaded files: 28,483 kB
Homepage: http://www.blackdown.org/ [blackdown.org]
Description: Blackdown Java Runtime Environment 1.4.2.01
License: sun-bcla-java-vm
* dev-java/sun-jre-bin [ Masked ]
Latest version available: 1.5.0.03
Latest version installed: [ Not Installed ]
Size of downloaded files
Re:64 bit linux :-)? (Score:2)
Re:64 bit linux :-)? (Score:2)
Great! You've found the source of the problem! Now the only thing left to to is rectify the situation by installing Gentoo. *grin*
flash, java, and ATI on amd64 (Score:2, Informative)
Applets? (OT) (Score:2)
Where do you find these many webpages using applets? I got the impression that applets were dead.
Re:64 bit linux :-)? (Score:2)
2) There are so 64Bit ATI Drivers. I am running them on this machine right now. Get your facts straight buddy.
3) Yeah it sucks that no 64Bit Browser Plugins exist yet. I don't know why though as 64Bit versions of Java 1.5 exist for both Windows and Linux.
Re:64 bit linux :-)? (Score:2)
I mean, Windows has even had a 64bit release of their OS around 10 years ago. Why a
64-bit linux (Score:4, Informative)
Re:64-bit linux (Score:2)
Re:64-bit linux (Score:2)
Re:64-bit linux (Score:5, Interesting)
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 difference... (Score:5, Informative)
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)
The difference...? (Score:2, Informative)
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 dat
Segments (Score:2)
The 8088/86 had a sixteen bit segments and 16 bit address and a 12 bit memory space! What was REALLY NASTY was that the you could have several combinations of segment+offset point the the same stinking physical memory location! That is also why a lot of programing languages where limited to 64
Re:Segments (Score:2)
From the top of my head - no guarantee that my memory is accurate.
"tiny" was were the code and dat
Re:Segments (Score:2)
If I remember the 286 still did not have a flat address space. Can't be sure since I was programming on the Amiga then. Boy going back to dos SUCKED. The 386 was the first Intel chip that was not a freaking nightmare. Now the whole protected vs real mode was still a minor nightmare.
In 32-bit protected mode... (Score:2)
The mapping was as follows:
Segment ID:Segment-relative address -> (segment descriptor) -> flat 32bit address
Flat address -> (page table) -> physical address
This was done to be somewhat compatible with 16-bit instructions in 16-bit modes. Later intel introduced PAEs which used parts of the segmentation mechanism to implement "weird ass vm mode", so you could have 36-bit of physical address with 32-bit pointers.
PAE was not nearly as bad as the 16->32 relationship
64-bi
Re:64-bit linux (Score:5, Funny)
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!
64-bit Linux (Score:5, Insightful)
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).
Re:64-bit Linux (Score:2)
...and quite a few userspace apps were broken on Linux/Alpha (I spent quite a bit of time with Linux on EV5).
But not because of backwards compatibility issues so much as bad code, written by bad coders.
The minor issues you're going to come across due to the true development environment differences between 32 bit and 64 bit code will be fairly minor in comparison to the problems with broken code that just happened to work in 32 bit mode.
All the world is not a Vax, not a Sun, and definitely not a 32 bit x
Re:64-bit Linux (Score:2)
IMHO, the goodness of open source code comes more from people trying to port the code to other platorms than from the "millions of eyeballs" looking over the code.
Re:64-bit Linux (Score:3, Insightful)
But not because of backwards compatibility issues so much as bad code, written by bad coders.
Most all were fixed many years ago. Thank the Debian Project for continuing to build against Alpha, and tracking bugs against it. Upstream then makes their s/w 64-bit clean for everyone.
Of course, if fewer programs were written in C, the problem would be minimized.
All the world is not
Gates: transition will happen 'rapidly' (Score:2)
64-bit linux (Score:5, Informative)
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
Re:64-bit linux (Score:2, Informative)
Re:64-bit linux (Score:2)
Uh...probably not (Score:2)
All the applications I am using now are 32-bit, in spite of having a 64-bit CPU and a 64-bit OS kernel. However, this is Solaris, so who knows if Microsoft will be as successful.
For people who used the first releases of Solaris 7 (my memory is fuzzy), were there many issues back then? I would think there would be more issues in converting a 32-bit program into a 64-bit one, rather than having any issues running a 32-bit program on a 64-bit kernel.
Re:Uh...probably not (Score:2)
In C, the 64-bit integer type is usually called "long long", so the big issue, as usual with C, is pointers and casting.
For 25 years now (starting with the MC68000, VAX, SPARC, etc), pointer has equalled int in bit size on 99+% of all installed systems.
But 64-bit systems have been around for ~15 years, so that's when Unix/POSIX C programmers
*WHEN* 64-bit linux comes out? (Score:4, Informative)
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.
Don't worry about it... (Score:5, Insightful)
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.
Re:Don't worry about it... (Score:2, Insightful)
Re:Don't worry about it... (Score:2, Funny)
Oh yeah, what about Java? (Score:3, Interesting)
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 t
Re:Oh yeah, what about Java? (Score:2)
I believe the Virtual Machine will handle any differences in the hardware. Remember that Java is the "write once but pray everywhere" programming language.
Re:Oh yeah, what about Java? (Score:2)
Re:Oh yeah, what about Java? (Score:5, Informative)
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.
Re:Oh yeah, what about Java? (Score:2)
Re:Oh yeah, what about Java? (Score:2)
That is not a problem. However that arrays in Java are limited to 2^31 elements will probably be a real problem at some point. I don't know how they are going to address this.
-- kryps
64-bit Java works fine. (Score:2)
mahlen
Problem with C/C++ pointers (Score:2)
Re:Problem with C/C++ pointers (Score:2)
Huh? Win32 certainly made that assumption, passing pointers around in DWORDs, but there's never been any guarantee of it in the language. I happen to agree that 64 bit platforms should have made int 64 bits, but in terms of "biting the bullet", Alpha, SPARC64 and all of the other platforms mentioned elsewhere here have already gotten most of the job done for the *NIX world. If you're on Windows, there's probably more of a problem, but that ha
[OT] About your sig... (Score:2)
Everytime I see your sig, I wonder what the heck is going on.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
1. Yoda said that, not Spock
2. Dr. Spock was an idiotic moron who wrote books about childcare in the 40s , 50s and 60s.
3. Spock on Star Trek was never a Dr. (phd or md)
4. Given that the first 3 points make your sig whacked out, where the heck did the stardate come from?
I had considered that all those factors were just there to
Re:[OT] About your sig... (Score:2)
Re:Don't worry about it... (Score:2)
Dr Spock (1903-1998) was a pediatrician turned child/family psychologist
64-bit is NOT NEW (Score:2)
There is the occasional badly-behaved audio or video application, coded originally on 32-bit x86 Linux, that must be hammered into shape. But it happens quickly enough that my Alpha is, and has been for years, a fully modern 64-bit deskto
Re:64-bit is NOT NEW (Score:2)
I am only being partially fasicious there. With all of the attention on media processing these days, it may make sense to throw 16bytes around at a time instead of 8. In fact, aren't many vector processors and GPUs structured around 128bit words already?
Re:64-bit is NOT NEW (Score:2)
Re:64-bit is NOT NEW (Score:2)
Windows NT/Alpha put the processor in 32 bit mode.
That's how most OpenVMS code ran for a long time, too.
Re:64-bit is NOT NEW (Score:2)
The ultrasparc I got for free is 32 bit.
Then it's not an UltraSparc. An Ultra is a sun4u architecture machine, which is the 64bit successor to the 32bit sun4m architecture.
16bit huh? 24bit yes (Score:2)
There were some problems with some software but then again Apple always warned about thos upper 8bits.
Re:16bit huh? 24bit yes (Score:2, Interesting)
And I too remember plenty of warning for getting "32 bit clean".
Re:16bit huh? 24bit yes (Score:2)
And it could still be fitted in a 64 pin package.
Thunking! (Score:2, Interesting)
Thanks for the walk down memory lane.
OK - is this the most stupid AskSlashdot today ? (Score:4, Funny)
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.
Re:OK - is this the most stupid AskSlashdot today (Score:2, Interesting)
Note: I'm a gamer.
Re:OK - is this the most stupid AskSlashdot today (Score:2)
Re:OK - is this the most stupid AskSlashdot today (Score:2)
64 bit question (Score:2)
Re:64 bit question (Score:2)
Why do they say it accesses 2^24 bytes only?
That must be in real mode, where the 8086 back from 1981(?) is emulated. All x86's boot into this mode, even today... and waste our time, money, and hardware/BIOS developers nerves. In real mode you only have 16bit opcodes and registers but needed to be able to address more than just 64kB of RAM, so they introduced a way (segment and offset) to address with 24bit (like the whole processor, this was a quick hack to bring a 16bit version of the 8080 to market as
Re:64 bit question (Score:2)
Memory is nowadays always addressed in bytes.
2^64 bytes, instead of 2^64 64bit words.
True on common hardware, but not on all hardware. (Score:2)
Translation (Score:2)
The system can actually use 2^40 bytes (a terabyte) of RAM
48 bits virtual:
The system may use 64-bit pointers, but the top 16-bits are ALWAYS zero.
(Virtual memory addresses are translated into physical addresses by page tables... swapping and memory mapped files and all sorts of fun stuff is done with these tricks that make you look like you have more "memory" than is actually there)
This is important because the page tables that translate virtual addresses into physical addresses are going
Re:Translation (Score:2)
Thank you, thank you, I'll be here with you all week!
Errr... (Score:2)
Either you make your pagetables have less entries per page with the additional address bits, or you aim for a reasonable maximum, with the knowledge that eventually you'll release a version 2 with more virtual address space and a new pagetable layout.
Wasting space in pagetables is bad for performance. Totally kills your cache and makes flushing TLBs more costly.
Bitness != Pain (Score:4, Informative)
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.
Re:Bitness != Pain (Score:2)
Re:Bitness != Pain (Score:2, Informative)
Re:Bitness != Pain (Score:2)
Times Have Changed (Score:2)
Well, if you're using low level code still, like Win32 constructs and other windows C++ specific data types, you may indeed be faced with work to do. I remember arguments passing from 16bit OLE interfaces into 32bit C++ EXEs that was troublesome. However in this switch, the code should run fairly fine.
If my above assumption is indeed your worry, I would recommend rebuilding your C
How hard is it, (Score:4, Insightful)
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.
Re:How hard is it, (Score:4, Informative)
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.
easy to quantify (Score:3, Interesting)
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 (Score:3, Interesting)
Re:easy to quantify (Score:2)
And that was "only" Intel. Everyone else had the brains to build 32 bit systems in the late 70s and early 80s.
Re:easy to quantify (Score:2)
Re:easy to quantify (Score:2)
http://www-128.ibm.com/developerworks/library/pa- m icrohist.html?ca=dnt-61 [ibm.com]
"In 1979, Motorola introduced the 68000. With internal 32-bit registers and a 32-bit address space, its bus was still 16 bits due to hardware prices"
http://en.wikipedia.org/wiki/Acorn_RISC_Machine [wikipedia.org]
When 64-bit linux comes out? (Score:3, Insightful)
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.
I have an idea. (Score:2)
Next 'Ask Slashdot'; "Does anyone know if BonzaiBuddy runs on the internets?"
It's a valid question (Score:2, Interesting)
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 (Score:3, Interesting)
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 address
As others have already observed ... (Score:2)
transition..? (Score:2)
Shock? What shock? (Score:2)
Now, 64 bit Linux has been here for a long time, and since most drivers are open source, the port is complete. There will be no shock, no pain. It's just that for optimal performance you'll want to recompile more applications than on 32 bit.
Windows is Not Quite There, though I have a 60 day trial on my desk. Here drivers are mostly closed source, which causes prob
Worry about more bloatware (Score:2)
This isn't a big deal for proper unix developers (Score:2)
Shock? I think not. (Score:2, Interesting)
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 qui
amd64 has it's own set of problems (Score:2)
Now add to this a processor that can go both ways without rebooting. TWO environments running at the same time (though the OS is strickly 64 bit). Do we have dual libraries or chroot? It's a LOT easier to have only a native 64 bit env
Kids these days... (Score:3, Interesting)
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.
Not a problem (Score:2)
If all of your memory needs can fit within a 32bit address space, you've got nothing to worry about.
Installed AMD64 Debian last week (Score:2, Interesting)
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
Re:Possible answers (Score:2)
Re:Longhorn? (Score:2)
Considering how much Longhorn technology has been (or will be) backported into Windows XP, that's not surprising. Hey, maybe Microsoft will throw in the kitchen sink free of charge!
Re:This is why you need to program in managed code (Score:2)
Pretty much any open source app works on loads of different architectures. It's not hard to fix code to do that.
Re:This is why you need to program in managed code (Score:2)
Porting across platforms doesn't even come into this argument.