http://www.osnews.com/story/14349/Porting_Linux_Applications_to_64-bit_Systems Exploring the Future of Computing en-us Copyright 2001-2009, David Adams adam+nospam@osnews.com Tue, 10 Nov 2009 09:49:05 GMT http://www.osnews.com/images/osnews.gif http://www.osnews.com http://osnews.com/thread?115221 http://osnews.com/thread?115221 one day you have to "port" (or rewrite) your apps to a 128 bits cpu and then to a 256 bits platform and so on and on.

why just dont start specifying some int128 or long256 already? Sun, 16 Apr 2006 08:39:00 GMT donotreply@osnews.com (PipoDeClown) Comments http://osnews.com/thread?115222 http://osnews.com/thread?115222 I think the title is somewhat misleading.As long as you have the source you're in princype 64-bit ready.Isn'þ a 32 bit app per definition able to run on x86_64?

On my Ubuntu box ijust enter "apt-get build-dep kradio" in order to get all the development packages needed to build a 64-bit *.deb package from "32-bit" source code.Than a "fakeroot apt-get install -b source kradio" is enough to build a fresh 64-bit kradio package. Sun, 16 Apr 2006 09:06:00 GMT donotreply@osnews.com (netpython) Comments http://osnews.com/thread?115224 http://osnews.com/thread?115224 um, #include , use (unsigned) (long) (long) int. You don't have to use int8, int16, int32, int64, intOMG, it's typedefed for you. Sun, 16 Apr 2006 09:07:00 GMT donotreply@osnews.com (postmodern) Comments http://osnews.com/thread?115225 http://osnews.com/thread?115225 um, #include , use (unsigned) (long) (long) int. You don't have to use int8, int16, int32, int64, intOMG, it's typedefed for you. Sun, 16 Apr 2006 09:09:00 GMT donotreply@osnews.com (postmodern) Comments http://osnews.com/thread?115230 http://osnews.com/thread?115230 .. it is not needed? Sun, 16 Apr 2006 09:30:00 GMT donotreply@osnews.com (mOOzilla) Comments http://osnews.com/thread?115231 http://osnews.com/thread?115231 Ignore this comment, meant to reply to PipoDeClown.

Don't drink and post kids. Sun, 16 Apr 2006 09:30:00 GMT donotreply@osnews.com (postmodern) Comments http://osnews.com/thread?115232 http://osnews.com/thread?115232 Why must we specify a size for an int, cant we just treat an integer as an integer regardless of size? This is the problem one gets when using low level SYSTEM languages for applications no? Sun, 16 Apr 2006 09:31:00 GMT donotreply@osnews.com (mOOzilla) Comments http://osnews.com/thread?115234 http://osnews.com/thread?115234 Sorry I cannot edit this board editing is broke.


The underlaying size of a type is the job of the runtime, use a HIGHER LEVEL language for HIGHER LEVEL applications. Are you writing a compiler? an OS? NO! Its a bad choice of tools that make you have these migration problems later on. Sun, 16 Apr 2006 09:33:00 GMT donotreply@osnews.com (mOOzilla) Comments http://osnews.com/thread?115235 http://osnews.com/thread?115235 There is also a stigma around mixing languages for a solution, alot of people think, oh I have to code this in C so it ALL must be in C!. We develop blindy and by fear, look at any project comming up to RTM, we darnt change things because we do not know what the result will be, Dev by FEAR anti-pattern Sun, 16 Apr 2006 09:34:00 GMT donotreply@osnews.com (mOOzilla) Comments http://osnews.com/thread?115239 http://osnews.com/thread?115239 The problem with your HIGHER LEVEL language idea is that it will perform like crap.

Higher level languages like Perl or Java do not use variable sized integers by default (although it's an option), because it adds a huge amount of complexity to every addition.

You can go ahead and do what you want but no one will run your program because it'll be so slow. Sun, 16 Apr 2006 10:07:00 GMT donotreply@osnews.com (zlynx) Comments http://osnews.com/thread?115241 http://osnews.com/thread?115241 Well with applications that require user intervention alot then speed is not an issue. Computer performance doubles so quickly, shelf life of PCs is 2 months in the store. Get a faster machine if you really want that killer app. If my machine runs slow, then I get a better one. Its the same old excuse, MUST CODE C, it will be uber fast but what are you really saving, not alot for user based apps. Sun, 16 Apr 2006 10:10:00 GMT donotreply@osnews.com (mOOzilla) Comments http://osnews.com/thread?115242 http://osnews.com/thread?115242 Ironically, the day all the applications use high level languages, you will probably be the first to start complaining because of the massive mamory usage and inefficinecy of all of the programs, and you'll be arguing that people should have been using a little bit lower level languages.

I think every language has its place, but the solution is not to abandon lower level languages except where its impossible to use higher level languages. Higher level languages are great in some places, such as for plugins for programs as they are not likely to be packaged and prepared for all of the distributions and architectures. Its also great where rapid development and deployment is one of the top priorities, but for long term solutions that aren't rapidly changing and all that stuff, lower level languages are preferable due to the lower performance footprint IMO. Sun, 16 Apr 2006 10:15:00 GMT donotreply@osnews.com (aent) Comments http://osnews.com/thread?115246 http://osnews.com/thread?115246 Because more bits makes code bigger and even slower. The reason we now have 64-bit architectures is that 32-bit machines can access only 4 GB of memory. Sun, 16 Apr 2006 10:54:00 GMT donotreply@osnews.com (tihirvon) Comments http://osnews.com/thread?115249 http://osnews.com/thread?115249 *Snaps*

Why the hell there's so many people bashing C and C++ around here!!!!?

Can't these just keep coding in their and leave c/c++ programmers and aprentices alone..? Sun, 16 Apr 2006 12:20:00 GMT donotreply@osnews.com (joelito_pr) Comments http://osnews.com/thread?115252 http://osnews.com/thread?115252 right tools for the right job. imagine coding a website in C, or an OS in java... *shudders* Sun, 16 Apr 2006 12:48:00 GMT donotreply@osnews.com (Mr. Tan) Comments http://osnews.com/thread?115260 http://osnews.com/thread?115260 > right tools for the right job. imagine
> coding a website in C, or an OS in java... *shudders*

www.jnode.org

Just because it can't imagine something doesn't mean it's impossible or even a bad idea. Sun, 16 Apr 2006 13:59:00 GMT donotreply@osnews.com (Morin) Comments http://osnews.com/thread?115262 http://osnews.com/thread?115262 I'm not sure it's a good idea to use Moore's law to excuse heavier applications. It tends to get offset by Parkinson's Law and Gates's Law I for one find that a shame.

Gates's Law -
"The speed of software halves every 18 months."

Parkinson's Law -
"Data expands to fill the space available for storage" Sun, 16 Apr 2006 14:04:00 GMT donotreply@osnews.com (MamiyaOtaru) Comments http://osnews.com/thread?115263 http://osnews.com/thread?115263 Well the main reason is Apple only really seem to support Objective-C anything else its down to the shell and hacks. Sun, 16 Apr 2006 14:06:00 GMT donotreply@osnews.com (mOOzilla) Comments http://osnews.com/thread?115264 http://osnews.com/thread?115264 Just because we DESCRIBE our application at a higher level and without regard to sizes of types doesnt mean it has to be INEFFICIENT. A smart compiler and runtime will be able to manage these efficiently. We need smarter tools. We have been trapped at this level of development for decades. Sun, 16 Apr 2006 14:07:00 GMT donotreply@osnews.com (mOOzilla) Comments http://osnews.com/thread?115271 http://osnews.com/thread?115271 You know, this might have been an interesting article (as others on IBM DeveloperWorks have been) if only it were readable. As it is, I found line lengths exceeding 160 characters; human-factors research (which they have at IBM!) indicates that readability is best at line lengths of 55-65 characters, and in any case should not exceed 75 characters. Readability degrades rapidly at longer line lengths.

As far as tolerating 160+ character lines: Life is too short! Sun, 16 Apr 2006 15:26:00 GMT donotreply@osnews.com (cjcoats) Comments http://osnews.com/thread?115273 http://osnews.com/thread?115273 Computer performance doubles so quickly, shelf life of PCs is 2 months in the store.

Maybe, but you can still get by with a computer you bought 6 years ago. Unless, of course, you're playing games ... or using a lot of Java apps Sun, 16 Apr 2006 15:34:00 GMT donotreply@osnews.com (WorknMan) Comments http://osnews.com/thread?115274 http://osnews.com/thread?115274 The real problem is with the reuse.
We need to parse an xml configuration file so we reuse an XML parser with support for namespaces, validation and all.
You design an OS for a mobile phone around Linux by adding layers instead of removing unused parts.
Sure, it saves up development time and cost.
The result, however, is bloat and slower code.

This calls for frameworks where you pick and choose the parts you want. frameworks that are flexible because you can compile them with the needed functionality, or leave the stuff you don't need at the link phase.

You have the perfect system when there is nothing to remove, not when there is nothing more to add. Sun, 16 Apr 2006 15:36:00 GMT donotreply@osnews.com (hashnet) Comments http://osnews.com/thread?115275 http://osnews.com/thread?115275 unfortunately, your code can only perform when you understand how it executes.
Any impedance mismatch between the platform and your code/language is punished by performance degradation.
This does not imply you have to use low level, system languages.
See ocaml as an example of a higher (than c) level, efficient language.

Often, absolute best performance is not the overriding goal. Correctness, and ease of development are at least as important.
Just fall back to C for the parts of the system that must be low level, system access. Sun, 16 Apr 2006 15:43:00 GMT donotreply@osnews.com (hashnet) Comments http://osnews.com/thread?115276 http://osnews.com/thread?115276 This article is aimed at programmers and it's obvious alot of the people responding aren't. There not talking about recompiling something in your stupid linux distro.

C & C++ is a high level language, it's a high level compiled language, but it is a high level language. Java is a high level language as well but is usually run in a VM and therefore is useless for many things.

The nice thing about C and C++ as many faults as it has is you can acomplish anything with it pretty much anything. And if you can't then look, there's assembly, and if you still can't then look there's some ants. It's an easily portable language that if writen efficiantly isn't that much worse off than assembly.

The lesson here is don't assume that an unfixed-bit type it's going to be a fixed-bit size. Define your types just like many embedded engineers do with every variable. It doesn't add much work to programming and makes code a hell of alot clearer and more precise. And don't respond to articles that you quite obviously can't wrap your head around.

This is a quite good article discussing some very good programming practices. Mod me down if you must but realize you an ignorant p***k if you do, and that this is post is atleast partially directed at you. Sun, 16 Apr 2006 15:49:00 GMT donotreply@osnews.com (jrichey_98) Comments http://osnews.com/thread?115288 http://osnews.com/thread?115288 Programmers should choose the max int size supported by the CPU for most things. For data in structures and arrays, they should choose a smaller size. Sun, 16 Apr 2006 16:22:00 GMT donotreply@osnews.com (TADavis) Comments http://osnews.com/thread?115305 http://osnews.com/thread?115305 > C & C++ is a high level language, it's a high level compiled language, but
> it is a high level language.

Compared with other languages available today, C is pretty low-level. I would call it a good, somewhat platform-abstracting assembler. That's exactly why people use it for optimization.

> Java is a high level language as well but is usually run in a VM and
> therefore is useless for many things.

You say "usually" but treat it as "always". The JVM is a specification for the interface between the compiler front-end and the back-end, which can be either a compiler or an interpreter. Writing a back-end that compiles class files to native code is compiler-writing 101.

> It's an easily portable language that if writen
> efficiantly isn't that much worse off than assembly.

Right, C is so portable that you see many C programs cluttered with #define's to deal with the pecularities of each implementation. You should stop for a moment and think why this isn't the case with Java. Sun, 16 Apr 2006 17:10:00 GMT donotreply@osnews.com (Morin) Comments http://osnews.com/thread?115307 http://osnews.com/thread?115307 You shouldn't use stdint.h, because it isn't portable. Use inttypes.h instead. Sun, 16 Apr 2006 17:12:00 GMT donotreply@osnews.com (unavowed) Comments http://osnews.com/thread?115313 http://osnews.com/thread?115313 > Programmers should choose the max int size supported by the CPU for most things.

No, programmers should always choose the smallest possible int size for the task at hand. For example, to store a number between 0 and 20000, use a 16-bit int ( Sun, 16 Apr 2006 17:16:00 GMT donotreply@osnews.com (Morin) Comments http://osnews.com/thread?115317 http://osnews.com/thread?115317 I forsee a CPU which has a 64-bit stack and a RISC instruction set which handles ints and floats like the FPU. It's native will be 64-bit. I don't see sizes larger than 64-bit emmerging. 64-bit is the end of the line. I've written an operating system and compiler with this in mind--LoseThos. (http://www.justrighteous.org) Picking-and-choosing sizes just leads to errors. Obviously, when many instances of a variable are present--arrays, you pick the appropriate size. Sun, 16 Apr 2006 17:24:00 GMT donotreply@osnews.com (TADavis) Comments http://osnews.com/thread?115331 http://osnews.com/thread?115331 "You know, this might have been an interesting article (as others on IBM DeveloperWorks have been) if only it were readable. As it is, I found line lengths exceeding 160 characters; human-factors research (which they have at IBM!) indicates that readability is best at line lengths of 55-65 characters, and in any case should not exceed 75 characters. Readability degrades rapidly at longer line lengths."

"As far as tolerating 160+ character lines: Life is too short!"

I'm sure you did the right thing... Scrolled to the bottom of the article to the "Rate this page" section, and submitted this to the folks at IBM. You know, the people who can actually do something about it. I'm sure you're not just complaining Sun, 16 Apr 2006 17:59:00 GMT donotreply@osnews.com (foobar) Comments http://osnews.com/thread?115339 http://osnews.com/thread?115339 Isn'þ a 32 bit app per definition able to run on x86_64?

Able to run, yes. Run correctly? That depends. If the programmer made certain assumptions about how large certain data types are, those assumptions may not hold on a 64-bit system.

Honestly, something with a good clean code base shouldn't have any trouble. Programs written in higher level languages shouldn't either, but there are quite a few C/C++ programs out there that rely on some ugly code which might do the wrong thing on 64-bit systems. Sun, 16 Apr 2006 18:37:00 GMT donotreply@osnews.com (smitty) Comments http://osnews.com/thread?115344 http://osnews.com/thread?115344 I thought the article was useful because of two things I learned about 64 bit programming while reading:

1) There's more than one data model for 64 bit being used. I actually had the narrow-minded view that LP64 was the only model.
2) Integer literals are 32 bit by default and must be suffixed with L to make them 64 bit. The bit shifting example was an eye-opener. (1 Sun, 16 Apr 2006 19:04:00 GMT donotreply@osnews.com (joecool) Comments http://osnews.com/thread?115351 http://osnews.com/thread?115351 C++ is so great thats why Apple chose Objective-C which inherits from SmallTalk as opposed to C++ which takes alot from Simula and is a bloated peice of shat.

You talk about bloaty apps but what about the actual language C++! Its major bloat! If you want to achive anything decent you have to play with hacks and know the fine details of those hacks. I have seen too many bugs which can be put down misuse of the language. Simple, people who use those toys either abuse them or just dont know how to play with them so we take them away and go higher level, the time of hacking C++ is over unless very very specific reasons for going to that level. Sun, 16 Apr 2006 19:18:00 GMT donotreply@osnews.com (mOOzilla) Comments http://osnews.com/thread?115353 http://osnews.com/thread?115353 > Picking-and-choosing sizes just leads to errors.

I don't mind having the compiler choose an appropriate size - in fact, this is very nice. However, just picking the biggest size available on a machine for all tasks clouds one's vision for the fact that "biggest" is sometimes not big enough - i.e. it leads people to carelessly choose the native size when a variable-sized integer that could grow above 1000 bits would be appropriate. It's also space-consuming (memory) and time-consuming (memory transfers) to use the native size where a smaller size is sufficient, but as you said, this is only important when many instances are present. Sun, 16 Apr 2006 19:28:00 GMT donotreply@osnews.com (Morin) Comments http://osnews.com/thread?115469 http://osnews.com/thread?115469 Not true. As a previous poster said you're not obliged to develop _all_ your app with a higher level language, you can mix the solutions and have performances _AND_ productivity.
Python and Ruby are damn slow for CPU bound tasks, this doesn't mean your app will be slow for such operations but that you have to profile and substitute the bottlenecks with C or C++. Mon, 17 Apr 2006 08:59:00 GMT donotreply@osnews.com (bsdlike) Comments http://osnews.com/thread?115476 http://osnews.com/thread?115476 There are more 64 bit architectures than x86_64, and those may not support backwards-compatibility.

There's more than x86 out there, remember. Mon, 17 Apr 2006 09:54:00 GMT donotreply@osnews.com (Knuckles) Comments http://osnews.com/thread?115506 http://osnews.com/thread?115506 Yip. Mon, 17 Apr 2006 12:32:00 GMT donotreply@osnews.com (netpython) Comments http://osnews.com/thread?115580 http://osnews.com/thread?115580 'm sure you did the right thing... Scrolled to the bottom of the article to the "Rate this page" section, and submitted this to the folks at IBM...

Yes. And not for the first time, either.

--cjcoats Mon, 17 Apr 2006 15:18:00 GMT donotreply@osnews.com (cjcoats) Comments http://osnews.com/thread?115616 http://osnews.com/thread?115616 I'm sorry I wasn't clear. I meant that forcing a high level language to use variable-sized integers for all operations will perform like crap. Mon, 17 Apr 2006 18:16:00 GMT donotreply@osnews.com (zlynx) Comments http://osnews.com/thread?115805 http://osnews.com/thread?115805 The biggest problem is assumptions, and the article makes that pretty clear:
1.) People assume | int | == | void * |. This is true, on x86. This isn't true on x64.
2.) People assume a certain endianness. This is a nasty assumption.
3.) People assume that because it just worked, the code works. That's not necessarily true at all...

I don't foresee a move to 128bit processors anytime soon... There's not a lot of reason. Special routines exist to work with larger numbers today, you can use a 32bit machine for numbers that wouldn't fit in a 128bit computer with a constant time added for every operation (and yes, you'd add constant time for a 128bit machine too, just less of it).
And 64bit machines allow for a lot of memory. 2^32 times as much as 4GB . That's 4 billion * 4 billion -- ish. Or 16 Quintillian I think?
Sure, people will have that much RAM eventually, but will we even still use silicon transistors then?

But I might be being shortsighted. Maybe there will be another reason to move off 64bit to something higher. Tue, 18 Apr 2006 04:42:00 GMT donotreply@osnews.com (ma_d) Comments http://osnews.com/thread?115806 http://osnews.com/thread?115806 You're supposed to. Ever written 20,000 lines of c before? I bet you'd mess it up occasionally too . Tue, 18 Apr 2006 04:43:00 GMT donotreply@osnews.com (ma_d) Comments http://osnews.com/thread?115807 http://osnews.com/thread?115807 http://en.wikipedia.org/wiki/High_level_language#Relative_meaning

I wouldn't consider c or c++ to be high level. I'd call them systems languages.


You can accomplish the same set of tasks with all turing complete languages, that's the point . It's just that some are _MUCH_ better suited for some tasks than others.

But you're definitely right about the article. It is good, and it is intended for programmers. Tue, 18 Apr 2006 04:49:00 GMT donotreply@osnews.com (ma_d) Comments