×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

32-bit to 64-bit - Obsolesence Pains Again?

Cliff posted more than 8 years ago | from the will-history-repeat-itself dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

184 comments

Happy noises (4, Interesting)

bluelip (123578) | more than 8 years ago | (#12493668)

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

Re:Happy noises (-1, Troll)

Anonymous Coward | more than 8 years ago | (#12494567)

You Libs live in such a cartoonish world. You have to simplistically label things as good and evil, even if they're basically the same, since trying to keep track of nuances is too taxing for your brains.

Re:Happy noises (0)

Anonymous Coward | more than 8 years ago | (#12495852)

thank you kind sir for posting anonomously... the world is not simple is it? well, for me it is, probably because i am not and fucking IDIOT

Re:Happy noises (0, Flamebait)

Anonymous Coward | more than 8 years ago | (#12497004)

AMd has been good to us lately. i think they'll continue to 'do the right thing'. Maybe they're the Google of hardware.

How so? Do they track what sites you visit and sell the content of emails to advertisers? Or are they just generally hypocrites and assholes?

Take your disgusting fanboiism over to the Apple-section, you fucking "omg teh googel is soooo shweet"-moron.

may i be the first to say: (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#12493675)

lol

Not Necessarily (1)

iced_773 (857608) | more than 8 years ago | (#12493683)

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.

Possible answers (0)

Neil Blender (555885) | more than 8 years ago | (#12493690)

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.

64 bit linux :-)? (5, Insightful)

Crimsane (815761) | more than 8 years ago | (#12493701)

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.

Re:64 bit linux :-)? (2, Informative)

Rylz (868268) | more than 8 years ago | (#12493998)

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.

  1. Macromedia Flash. I know this will be among the first ported when average people actually start using 64-bit CPUs, but at the moment it is very annoying to have to switch to my 32-bit machine once a week to see the new Strongbad email!
  2. ATI Drivers. It was probably a bad idea to get an ATI card for a Linux system, but when the drivers not only don't work, but don't exist for my architecture, I really feel like a dumbass.
  3. Sun Java. I hate Java and really dislike Sun, but applets are currently used on far too many web pages. I am patietly awaiting Apache's eventual F/OSS implementation of Java!

There are more, but those are the basics... I hope the move of the general public to 64-bit is quick so that the few closed-source programs that I still use will be ported!

Re:64 bit linux :-)? (2, Insightful)

RuneB (170521) | more than 8 years ago | (#12494149)

Why don't you just use a 32-bit compiled browser/mail program instead of switching computers?

Re:64 bit linux :-)? (5, Informative)

croddy (659025) | more than 8 years ago | (#12494165)

  1. 32-bit Flash works just fine on 64-bit gentoo. Install 32-bit Mozilla or Netscape binaries, and install the Flash plugin there. No need to switch machines, just switch browsers.
  2. ATI Drivers: I'm afraid you're on your own here.
  3. Sun Java 5 runs just fine on 64-bit gentoo, even if it is missing a browser plugin. Install blackdown-jre and your applets should run just fine.

Re:64 bit linux :-)? (2, Informative)

Galuvian (755742) | more than 8 years ago | (#12496381)

Blackdown is still 1.4, at least on amd64 stable

* 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: 32,042 kB
Homepage: http://java.sun.com/j2se/ [sun.com]
Description: Sun's J2SE Platform
License: sun-bcla-java-vm

Re:64 bit linux :-)? (1)

prefect42 (141309) | more than 8 years ago | (#12496999)

I wouldn't worry too much about drivers. ATI have produced drivers for IRIX 64bit and Linux IA64 (for SGI) so they really shouldn't have too much trouble with things.

Re:64 bit linux :-)? (0)

Anonymous Coward | more than 8 years ago | (#12497498)

Yeah, but gentoo seems to be the only distro that'll let you do this; 32-bit flash will not install on my Ubuntu. I've seen a couple articles for gentoo.

http://gentoo-wiki.com/HOWTO_AMD_64 [gentoo-wiki.com]

I'm about to see if I can get it installed w/ some of the info there. It might work with some patience.

flash, java, and ATI on amd64 (2, Informative)

Anonymous Coward | more than 8 years ago | (#12494166)

  1. The 32-bit flash plugin works if you run it in a 32-bit browser program, even on a 64-bit OS. As long as one of your web browsers is 32-bit, you can run flash from within that one. A good solution is to install both mozilla and firefox and make one of them the 32-bit version and the other one 64-bit.
  2. Proprietary ATI linux drivers for AMD64 are available [ati.com].
  3. Java applets are similar to flash -- the Sun java browser plugin will work if you use a 32-bit browser.

Applets? (OT) (1)

rve (4436) | more than 8 years ago | (#12496100)

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.

Re:64 bit linux :-)? (0)

Anonymous Coward | more than 8 years ago | (#12496220)

Fedora Core already had 64-bit version since last year. It is purportedly much faster than 32-bit on a 64-bit CPU, although I haven't tried it (I still use 32-bit FC3 on a 64-bit CPU because I'm too lazy to support multiple formats on several mixture of 32-bit/64-bit CPUs).

I will try 64-bit when I get around to it, or when I replace all my 32-bit CPUs.

BTW, 32-bit to 64-bit is not as bad as 16-bit to 32-bit. I think this is because 16-bit was too limiting at the time when applications were reaching the limits of 16-bit due to DOS/Windows too far delayed in providing 32-bit OS.

We haven't reached that limitation in 32-bit world and linux already comes up with 64-bit long before we feel the limit. Thanks to this competition by Linux, Windows is not far behind with 64-bit, so we won't feel the pain of limitations as before, when DOS/Windows had almost a monopoly and never advanced fast enough.

64-bit linux (3, Informative)

croddy (659025) | more than 8 years ago | (#12493705)

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.

Re:64-bit linux (0)

superpulpsicle (533373) | more than 8 years ago | (#12493921)

Hmm... but this is different. 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.

Re:64-bit linux (5, Interesting)

jnik (1733) | more than 8 years ago | (#12494101)

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:64-bit linux (1)

jojo tdfb (126691) | more than 8 years ago | (#12494924)

It wasn't just word size. The 16 bit mode on the x86 is way different than the 32 bit modes. There's a radical change in the way you address memory. I'm not exactly sure how amd's 64bit extention works, but I'd imagine it's not too different than your standard 32 bit protected mode. If it was, there'd be a lot more to upgradeing any app than a simple recompile(open source or not).

The difference... (4, Informative)

Ayanami Rei (621112) | more than 8 years ago | (#12495788)

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)

The difference...? (2, Informative)

jojo tdfb (126691) | more than 8 years ago | (#12495878)

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

Re:The difference...? (1)

cryoknight (313161) | more than 8 years ago | (#12496226)

64-bit memory addressing allows far greater than 4 gigs of ram, as well as file sizes above that.
Heck, an unsigned 64-bit int can go up to around 18 * 10^18... I doubt any OS will implement that amount of memory addressing for quite awhile...

So the difference, you ask?
1. Memory addressing
2. File size
3. much larger / more precise (for the floating point numbers) calculations

same thing, longer words (1)

jojo tdfb (126691) | more than 8 years ago | (#12496305)

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.

Re:same thing, longer words (1)

cryoknight (313161) | more than 8 years ago | (#12496352)

File size on a 32-bit OS (at least, 32bit windows) is a max of 4 gigs. On win64, the max file size is _much_ larger. Thus, I assumed that since 4 gigs is the max of an unsigned int, then the file size limitation must be due to the max word size of the machine (and the os).

File systems (1)

jojo tdfb (126691) | more than 8 years ago | (#12496436)

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.

Re:File systems (1)

cryoknight (313161) | more than 8 years ago | (#12496617)

Oh yeah! DOS!
Geez, for somebody who still uses DOS (mind you, with fat32), I'm surprised I forgot about that.
Checking Microsoft's pages, fat16 and fat32 both support up to 4GB file sizes, and NTFS up to 256 TB (but not the version used by NT4 and earlier, which wes limited to 8GB partition sizes).

Okay, scratch that file size stuff I had in the earlier post.

Re:64-bit linux (1)

mjsottile77 (867906) | more than 8 years ago | (#12496664)

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

I don't think it's going to be horsepower requirements this time around. The 8086 - 286 - 386 - 486 lineage was many big steps in both clock speed and features. The current 64-bit processors aren't that different from their predecessors in terms of architectural improvements -- sure, a bit more cache, some pipeline changes, and maybe some register tweaks. Nothing like the 386/486 SX vs. DX issue (math coprocessor vs not).



The only big change you'll see now will be addressable memory. Longer word size processors have been around for decades, and for the non-scientific user, they've proven to be pretty useless. And I sure hope apps don't suddenly bloat up such that Linux + Gnome/KDE requires >32-bit address space. (Usually I'd use Windows in this argument, but recently I've discovered that the latest Suse + KDE or Gnome performs slower than the same machine running XP. Sigh...)

Re:64-bit linux (0)

Anonymous Coward | more than 8 years ago | (#12497317)

Incorrect. The difference between 486sx and 486dx was the math coprocessor, but the difference between 386sx and 386dx was far more architectural, the 386sx was not a true 32bit system.

Re:64-bit linux (4, Funny)

swillden (191260) | more than 8 years ago | (#12494200)

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 (5, Insightful)

reynaert (264437) | more than 8 years ago | (#12493707)

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 (1)

SSpade (549608) | more than 8 years ago | (#12494982)

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

Re:64-bit Linux (1)

calidoscope (312571) | more than 8 years ago | (#12496109)

But not because of backwards compatibility issues so much as bad code, written by bad coders.

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 (2, Insightful)

Nutria (679911) | more than 8 years ago | (#12497307)

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


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 ... a 32 bit x86.

No, but 99.44% of it is... :/

Gates: transition will happen 'rapidly' (1)

jkauzlar (596349) | more than 8 years ago | (#12493712)

This link [yahoo.com] 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.

Re:Gates: transition will happen 'rapidly' (0)

Anonymous Coward | more than 8 years ago | (#12496396)

Chances are that it won't happen as quick as he'd like.

"quickly".

Not worried (1)

jgotts (2785) | more than 8 years ago | (#12493713)

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.

64-bit linux (4, Informative)

molo (94384) | more than 8 years ago | (#12493722)

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

Re:64-bit linux (2, Informative)

BJH (11355) | more than 8 years ago | (#12496276)

You missed out hppa (PA-RISC Linux), but otherwise you're absolutely correct.

Uh...probably not (1)

SunFan (845761) | more than 8 years ago | (#12493726)


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 (1)

Nutria (679911) | more than 8 years ago | (#12497361)

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.

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 started paying attention to proper coding practices. The Linux Alpha/SPARC64/PPC64/HPPA ports really acelerated the need to "do it right", because otherwise, the coder would get a stream of bug reports from people using 64-bit systems.

*WHEN* 64-bit linux comes out? (3, Informative)

Xtifr (1323) | more than 8 years ago | (#12493728)

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.

Don't worry about it... (4, Insightful)

Sheetrock (152993) | more than 8 years ago | (#12493770)

There was a period of years between 32-bit hitting the market and 32-bit being taken seriously as a development target by the majority of developers.

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... (2, Insightful)

shadowpuppy (629329) | more than 8 years ago | (#12494413)

Also keep in mind the 64k addres space limit if 16 bit systems is REALLY tiny. Back then many apps had to play games to get around it. It's one things for a document to go over 64k another for it to go over 4 gig.

Oh yeah, what about Java? (2, Interesting)

Latent Heat (558884) | more than 8 years ago | (#12495142)

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.

Re:Oh yeah, what about Java? (1)

creimer (824291) | more than 8 years ago | (#12495453)

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.

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? (1)

John Meacham (1112) | more than 8 years ago | (#12495680)

It is the same on x86_64. C ints are 32 bits. just pointers are 64 bits and your long longs are implemented in hardware so are faster. There is no need to make the default integer size bigger, it would just double the memory usage for no reason. 64 bit cpus are designed to do 32 bit math fast too for this reason.

Re:Oh yeah, what about Java? (5, Informative)

cratermoon (765155) | more than 8 years ago | (#12495726)

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

Re:Oh yeah, what about Java? (1)

moocat2 (445256) | more than 8 years ago | (#12496406)

The most common data model in C for 64 bit programming is LP64 [opengroup.org]. In this model, longs and pointers are 64 bits while ints are still 32.

In Java longs are already 64 bits which basically makes Java code 64 bit ready. If there is going to be any troubles, it will be with sloppy C code that assumes sizeof(int) == sizeof(long).

Re:Don't worry about it... (1)

StyXman (81792) | more than 8 years ago | (#12495298)

> Try not. Do or do not, there is no try
> -- Dr. Spock, stardate 2822-3.

That's Yoda [starwars.com].

Re:Don't worry about it... (1)

bladesjester (774793) | more than 8 years ago | (#12495963)

not to mention that it's Mr Spock.
Dr Spock (1903-1998) was a pediatrician turned child/family psychologist

Re:Don't worry about it... (1)

Frnknstn (663642) | more than 8 years ago | (#12496629)

Not to mention that the stardate is totally out of bounds, but he has had that .sig for a while. He keeps it as a kind of permanent troll. Maybe he should be modded as such?

64-bit is NOT NEW (1)

derinax (93566) | more than 8 years ago | (#12493776)

...forgotten, perhaps, regarding Windows since the Microsoft / DEC Alliance days. But I've been running NetBSD's pkgsrc [netbsd.org] on a fully 64-bit OS [netbsd.org] for many years now (not to mention some [sun.com] others [hp.com]). 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.

Re:64-bit is NOT NEW (1)

Corpus_Callosum (617295) | more than 8 years ago | (#12494416)

No, it's not new. This of course begs the question, "When are the 128bit processors going to hit the streets?"

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 (1)

Cmdr TECO (579177) | more than 8 years ago | (#12495035)

In fact, aren't many vector processors and GPUs structured around 128bit words already?

They're generally 4 x 32-bit. I don't know any with general-purpose operations on 128-bit words. Someone will correct me if I'm wrong (or even if I'm right, probably).

Re:64-bit is NOT NEW (1)

Cmdr TECO (579177) | more than 8 years ago | (#12494986)

I've got an Alpha I bought for $5 and an UltraSparc I bought for $2. That tells you something about how long 64-bit micros have been around.

Stepping back from micros, the first 64-bit Un*x was Cray's UniCOS in 1984; the second (and the first I used) was Control Data's (by HCR) in 1985. (And the trouble wasn't so much the 64-bit int as the 32-bit short, and pointers that filled the upper 48 bits of the word, and the null pointer that wasn't 0.)

Stepping back from Un*x, what was the first (exactly) 64-bit machine? I don't know. The earliest I know of was the Mellon Institute Digital Computer, 1954. (Some earlier machines had larger words, of course; the UNIVAC I had a 72-bit word.)

So, yeah, people are going to have trouble adapting.

Re:64-bit is NOT NEW (1)

M1FCJ (586251) | more than 8 years ago | (#12496572)

damn. The ultrasparc I got for free is 32 bit. On the other hand the JavaStation E I'm going to play with this weekend is also 32 bit (has SPARC CPU).

Re:64-bit is NOT NEW (1)

LizardKing (5245) | more than 8 years ago | (#12497065)

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.

Re:64-bit is NOT NEW (1)

Nutria (679911) | more than 8 years ago | (#12497403)

regarding Windows since the Microsoft / DEC Alliance days

Windows NT/Alpha put the processor in 32 bit mode.

That's how most OpenVMS code ran for a long time, too.

16bit huh? 24bit yes (1)

norwoodites (226775) | more than 8 years ago | (#12493848)

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.

Re:16bit huh? 24bit yes (2, Interesting)

Bill Dog (726542) | more than 8 years ago | (#12494538)

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

Re:16bit huh? 24bit yes (0)

Anonymous Coward | more than 8 years ago | (#12495525)

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.

Longhorn? (1)

WhatAmIDoingHere (742870) | more than 8 years ago | (#12493852)

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.

Re:Longhorn? (1)

creimer (824291) | more than 8 years ago | (#12495490)

People, for some reason, keep confusing XP 64bit with Longhorn.

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!

Thunking! (2, Interesting)

Wabbit Wabbit (828630) | more than 8 years ago | (#12494022)

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

Thanks for the walk down memory lane.

OK - is this the most stupid AskSlashdot today ? (3, Funny)

MerlynEmrys67 (583469) | more than 8 years ago | (#12494103)

Should we start a daily poll on the dumbest question to hit Ask Slashdot on a 24 hour period.

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 (2, Interesting)

WhatAmIDoingHere (742870) | more than 8 years ago | (#12494354)

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.

64 bit question (1)

line-bundle (235965) | more than 8 years ago | (#12494277)

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?

Re:64 bit question (0)

Anonymous Coward | more than 8 years ago | (#12494491)

Hardware these days is usually byte-addressable, so an individual address value gets you a byte, not the machine's natural wordsize. Today's 32 bit machines have all 32 address lines going all the way out to the chip, so they can address 2^32 *bytes* of memory.

Today's 64 bit chips are also byte-addressable, so the max they can address is 2^64 bytes, which is 18 exabytes. That's probably more RAM than has been built in the history of the world, so it's overkill for the time being. Since having those pins on the chip cost money, they don't put them all in. They certainly put more than 24, though! I vaguely remember there being a 40 bit model and a 48 bit model in the AMD stable.

/proc/cpuinfo (1)

name773 (696972) | more than 8 years ago | (#12494580)

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

Translation (1)

Ayanami Rei (621112) | more than 8 years ago | (#12495836)

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.

Re:Translation (1)

archeopterix (594938) | more than 8 years ago | (#12496585)

This is done because 2^48 is an incredibly huge amount of space...
So, are you saying that 2^48 bytes should be enough for everyone?

Thank you, thank you, I'll be here with you all week!

Re:64 bit question (1)

DarkDust (239124) | more than 8 years ago | (#12496754)

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 fast as possible... we're still paying for the awful design decisions made back then).

Re:64 bit question (1)

chthon (580889) | more than 8 years ago | (#12497067)

Memory is nowadays always addressed in bytes.

2^64 bytes, instead of 2^64 64bit words.

Bitness != Pain (3, Informative)

fm6 (162816) | more than 8 years ago | (#12494301)

The pain we experienced going from 16-bit to 32-bit Windows had nothing to do with bitness. Despite having the same name and a big feature overlap, these were actually two different OSs. The 16-bit OS evolved out of DOS, a nasty, buggy and incomplete OS designed by people who didn't even understand what an OS was supposed to do. The Windows layer didn't just provide GUI services, it kludged in basic OS functionality, like pre-emptive multitasking [wikipedia.org]. By contrast, 32-bit Windows was written from scratch by OS geniuses who had previously worked on VMS [wikipedia.org]. They did their best to provide backward compatibility, but there's a limit to what you can do about that wihout screwing up the new OS.

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 (1, Informative)

Anonymous Coward | more than 8 years ago | (#12494396)

Win95 was 32-bit. Win95 was based on DOS, not the OS/2|NT project.

Re:Bitness != Pain (2, Informative)

Bill Dog (726542) | more than 8 years ago | (#12494658)

Win95 was a 16/32-bit hybrid/bastardization. It ran both 16 and 32-bit apps natively (and you could thunk calls between them). The NT-based OS's were always 32-bits (or more now), and emulate a 16-bit layer when needed (the Windows on Windows, or WOW subsytem). I believe it was WinME that was the last of those bastardizations.

Times Have Changed (1)

mugnyte (203225) | more than 8 years ago | (#12494458)

I this the questioner is referring to the MS C++ and VB compatabilities that happened when DLL's were 16bit on 32bit windows.

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 .NET studio or raw compiler begin to learn C#. The C++ datatypes in MS Visual Studio should be defined adequately for your port.

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.

Re:Times Have Changed (1)

Bill Dog (726542) | more than 8 years ago | (#12494708)

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.

I agree. I also tend to think that since dual-core cpu's are going to become mainstream on the desktop, there'll be a sooner migration of things to take (or take more) advantage of multi-threading than the move to 64 bits.

This is why you need to program in managed code (1)

jbplou (732414) | more than 8 years ago | (#12494521)

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.

How hard is it, (3, Insightful)

way2trivial (601132) | more than 8 years ago | (#12494620)

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.

easy to quantify (2, Interesting)

epine (68316) | more than 8 years ago | (#12494832)


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 (2, Interesting)

MemoryDragon (544441) | more than 8 years ago | (#12496821)

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.

Re:easy to quantify (1)

Nutria (679911) | more than 8 years ago | (#12497432)

The main problem with the 16-32 bit transition was the dreaded segmentation

And that was "only" Intel. Everyone else had the brains to build 32 bit systems in the late 70s and early 80s.

When 64-bit linux comes out? (2, Insightful)

photon317 (208409) | more than 8 years ago | (#12495263)


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. (1)

jericho4.0 (565125) | more than 8 years ago | (#12495271)

How about you go here [justfuckinggoogleit.com], and find out a thing or two. Like the fact that we've been running 64-bit linux for years, now.

Next 'Ask Slashdot'; "Does anyone know if BonzaiBuddy runs on the internets?"

It's a valid question (2, Interesting)

jojo tdfb (126691) | more than 8 years ago | (#12496410)

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 (2, Interesting)

DarkDust (239124) | more than 8 years ago | (#12496720)

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 ?

As others have already observed ... (1)

isolationism (782170) | more than 8 years ago | (#12495758)

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

Shock? What shock? (1)

Frodo420024 (557006) | more than 8 years ago | (#12496711)

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?

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

Worry about more bloatware (1)

pcause (209643) | more than 8 years ago | (#12497066)

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.

This isn't a big deal for proper unix developers (1)

Viol8 (599362) | more than 8 years ago | (#12497281)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...