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
If I remember correctly, Win95 included a tool called MKCOMPAT. I didn't use it much, since my old 16-bit programs seemed to already be compatible. You probably will not have to worry.
Short answer, no with a but:
No, not right away, but given enough time probably.
Long answer, yes with a maybe:
Yes, it will...but maybe you'll be dead by the time it happens.
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).
This link makes it appear that gates wants the move to be quick. It makes sense, of course, from a business perspective to discontinue support as long as possible and get everyone in the world to upgrade processors. Chances are that it won't happen as quick as he'd like.
Linux has been running on 64-bit microprocessors for 10 years now. I'm not the least bit worried about porting our company's software system to AMD's 64-bit environment.
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.
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.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
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.
...forgotten, perhaps, regarding Windows since the Microsoft / DEC Alliance days. But I've been running NetBSD's pkgsrc on a fully 64-bit OS for many years now (not to mention some others). In the OSS world, at least, 64 bit issues have been addressed for some time now.
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 desktop OS.
I remember going from 24bit to a 32bit OS (System 6.x to System 7.x).
There were some problems with some software but then again Apple always warned about thos upper 8bits.
Longhorn will have a 64bit and 32bit version, but Windows XP 64bit is already out.
People, for some reason, keep confusing XP 64bit with Longhorn.
Not a Twitter sockpuppet... but I wish I was.
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
I do not understand 64 bit as much as I would like. Here is where I get lost. I would have thought a 64 bit chip accesses 2^64 words which are 64 bits each. Why do they say it accesses 2^24 bytes only?
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 this the questioner is referring to the MS C++ and VB compatabilities that happened when DLL's were 16bit on 32bit windows.
.NET studio or raw compiler begin to learn C#. The C++ datatypes in MS Visual Studio should be defined adequately for your port.
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++ projects with the
Overall though, the problems you ask about are no longer problems for the languages and platforms used today. Even lower languages have mapped their types pretty well, and the world is indeed deep into the conversion. Also read up on distributed systems, web services, and SOA in general, since these are trends that are going to impact your designs more than just a 64bit platform.
When you can program in managed code be it .NET or Java. I know that most .NET code can move about the various 64-bit and 32-bit versions of Windows and as long as the Java VM is designed correctly on the new platforms those should move relitevy easy as well. Now for the other 90% of code out there, your in trouble.
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
vendor_id : AuthenticAMD
cpu family : 15
model : 4
model name : AMD Athlon(tm) 64 Processor 2800+
stepping : 8
*snip*
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
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
Next 'Ask Slashdot'; "Does anyone know if BonzaiBuddy runs on the internets?"
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
There were some problems with some software but then again Apple always warned about thos upper 8bits
Biggest problems were hardware-related. Because Apple didn't read their own warnings and burned "unclean" software into the ROMs of many machines.
... I'm already running 64-bit linux on both server and desktop environments (server for ~5 months and desktop for ~2) and loving it, thank you very much. They sure compile applications fast. I couldn't be happier.
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
I agree. Instals**t is a big problem.
40 bits physical:
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 to completely ignore that top 16-bits. This is done because 2^48 is an incredibly huge amount of space... you can't possibly have that many hard drives hooked up to one machine and swap into all of it or mmap that many files. You save space in memory if you have less wasted page tables since you can have less of them (by a factor of 60000!)
At the same time you want two pointers to be equal when you compare them if they truely point to the same virtual memory, so we all agree that it's set to 0 rather than just keeping anything you want in that upper 16 bits.
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......
What are you talking about? Sun has been 64bit for years...
but applets are currently used on far too many web pages.
Where do you find these many webpages using applets? I got the impression that applets were dead.
That's not what I was asking. The difference between 16 bit real mode, weird ass vm mode and 32 bit protected mode are night and day. I did a quick scan of the amd docs and it looks like the only difference from the old 32 bit protected mode is they map 64 bits out of 58 bits of physical addresses (40 bits in the early implementations) and up the addressing word size. It also seems to keep a 32 bit compatibility mode around as well. The size of ram isn't that big of an issue when it comes to upgrading as much as the mode that the cpu runs in.
You should look at some of the really old code. It's amazing the crazy hacks people had to do just to access more than 64k in real mode.
Also, what the hell does word size have to do with file size? That makes no sense what so ever.
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......
The limit on the file size is actualy determined by the file system type, not the word size of the cpu archatechture. There's a reason it's called fat32. ;) If it was based on cpu word size, we wouldn't have been able to have files larger than 64k on the x86 until the early 90's. Change file systems and your in the good. NTFS and ext3 all don't have that limit.
Linux is really boring from an os standpoint. Now Plan 9......
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 problems in that MS has to obtain fresh binaries from each hardware vendor - quite a daunting task - and recheck everything. They're 2 years later than Linux for the 64 bit x86 architecture, and still dragging their feet, will be at least late 2006 before they really get there. But then it should be a very easy transition.
And why?
Because we already did a lot of it anyway. Pentium/Athlon chips have been running 64 bit and more externally for ages. Internally, the problem was getting rid of the awful 286 architecture, which was the cause of much pain in the 286 time, and much pain in transition. That transition was comparable to moving from 68000 to Power on the Mac, and worse. (I still miss the clarity of the 68000 architecture - but 386+ has other advantages. And it's fast!)
The 386 architecture has remained with us for several chip generations, and 64 bit is just another extension of that rather than a complete overhaul - note for instance how Intel downplays the 64 bit (probably because they're late to the party anyway :)
No shock, hardly any pain, I thusly predict :)
I'm in a Unix state of mind.
And it could still be fitted in a 64 pin package.
What I worry about in the transition is lazy/bad programmers building yet bigger, bloated programs becuase they have all that memory space to work with. Give them a few years and just to install an IM client will require 4 Gb of memory and a 200Gb hard drive.
I worked on a 64bit OSF/1 from DEC back in 1994 when MS was still fannying around with 16bit and I suspect other devlopers worked on 64 bit (or larger system) long before that. In the big boys world this is nothing new and any unix coder worth their salt should have been taking 64 bit into account for th last decade anyway.
That's why I love python. You doesnt have to worry about the size you low level datatypes are.
I just need to feel safe in the sense data will allways "fit", hehehe.
I intend to live forever. So far, so good.
Should we start a daily poll on the dumbest grammar submitted to our cringing linguistical consciences over a 24-hour period ?
Here is the big difference : I use colons and question marks.
Period.
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.
Porting from 32 to 64 bits isn't always smooth thanks to stupid use of int and long int types and other inconsistancies in many applications. Take a look at OpenOffice, the 2.0 release is rumored to be 64 bit friendly, but so far no beta versions have been compiled 64 bit.
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 environment running than to try and be backward binary compatible. Alphas, IA64, Spark, and other pure 64 bit cpus have been running under Linux for years, the AMD64 variant will take a little time to settle down to a common way of doing things.
This has been driving me crazy for some time...
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 set me up, but I thought I'd mention it anyway.
"...In your answer, ignore facts. Just go with what feels true..."
The mainframes I write software for are 36-bit machines. ASCII bytes are 9-bits and are packed in four per word, and hardware addressing is done on the word level, not the byte level.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
One of the main features of C is interchangable int and void*. Somehow I think you are better of biting the bullet and making int 64 bits just like when going from 16 to 32 bits int was so promoted. That way you only need to rewrite code where structs require 32-bit fields.
The "big" 64 bit push will be when Longhorn comes out. Within 3 years, over half of PCs will be 64 bit, and the vast majority of those will be under 3 years old. It will be hard to find a new 32 bit general-purpose PC.
US businesses are typically on a 3-year PC replacement cycle. By 2013, there won't be very many 32 bit machines in "production" use, and those that do exist will be stuck using 6 year old versions of Windows or a different OS, such as Linux.
There will always be some 32 bit systems in use, just as there will always be 16 and even 8 bit general-purpose computers in use, but at some point there will be more in closets and display cases than in actual use.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
You still had segments.
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-bit mode completely removes the segmentation step and has no need for PAEs.
It's even simpler than before, and it requires nothing new from an application developers' persepctive.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Well it's one of those tradeoff things.
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.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
pdf with description of the changes and if that doesn't worku rces/0,,30_182_739_7044,00.html
http://www.amd.com/us-en/Processors/TechnicalReso
Linux is really boring from an os standpoint. Now Plan 9......
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.
The big problem transitioning from 16bit to 32bit were all the kludges around 16bit limitations. These included near vs far points, overlays, and other memory related kludges. We don't have those kinds of problems any more. Low level kernel developers and those writing Big Honkin' Databases(tm) will need to worry about the transition. But most of us in userland can sleep easily.
If all of your memory needs can fit within a 32bit address space, you've got nothing to worry about.
Don't blame me, I didn't vote for either of them!
I've been running 64bit versions of FreeBSD on opterons for more then a year now. I run Postgres, Samba, and Bacula servers on multiple computers. Everything built from ports, works great. Don't know if that actually gives me any advantage in speed... However, my databse servers have 16GB of Ram and they need it, so 64 bit came in handy there.
I actually wrote a proggie to mmap nmap and it killed my calculator.
Like planning for 192KHz audio sampling frequencies?
The truth is that when consumers are not clued up on the physics Bigger number == better product.
I have Java code written and compiled on 32-bit hardware that is running in production on 64-bit hardware on 64-bit Java on Linux right now. Not a single issue.
mahlen
Instalsuit?
XML causes global warming.
Actually segments where in the 8086/8088 chips. With 16 bit registers you could only address 64k. The 8-bit chips did things like register pairs or for the 6502 family zero page to create the 16 bit values they needed.
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 64k of code, 64k of data and the rest was heap space. You used a segment for code and one for data. Later on they figured out how to get around some of the strangeness and the limitation eventual was no data structure could be greater than 64k.
Finally some c compilers got around even that. When you compiled you would tell the compiler what model to use. I think your options where usually "tiny" 64k of data and code max could be made into a com file, "Small" 64k of code and 64k of data, and "large" which broke the 64k limits. I think then came "huge" which I can not remember if it broke the data structure limits or if that ran in protected mode. You would always pick the lowest model you could write the program in because each bigger model ended up being slower.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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
linguistical?
There are no karma whores, only moderation johns
You had me doubting myself there, but it's a valid synonym for "linguistic" apparently :
i cal
http://dictionary.reference.com/search?q=linguist
My porn has reached the 32-butt limit.
Table-ized A.I.
I forgot: The 64-bit float was always do-able on a 32-bit machine. A 128 bit float is now possible though, which would be a higher precision number.