Quote:huh??? Unix platforms? what has that got to do with the processor, its an operating system.

The OS DOES have something to do with it. Tho the majority of the logic would remain the same (for subroutines doing the majority of your number crunching), you're going to become incompatible between OS' if you hook into OS specific features (i.e., Win32 API or *nix system calls). The OS will still be a consideration unless you're writing something that doesn't use system calls.

Quote:Hmm... aren't all programs made out of assembly language? When you ship an executable, isn't the program in assembly language format? Wouldn't that mean that I have the same restrictions in C++ as I do with assembly? Am I totally getting the wrong idea ?

Also, what exactly should I learn then? What is the name of the most generic, cross-platform (or otherwise good) assembly language?

No, when you ship a program that's been compiled in a HLL, it's in machine code, not ASM. It's a real pain in the ass to derive the ASM from the machine code since the von Neumann architecture makes no distinctions between instructions and data. Things can be quite confusing when you're looking at machine code and see it using an instruction as data and data as an instruction.

You seem to have the wrong idea of what cross-platform means. AMD and Intel procs are the SAME platform (x86) with a relatively small subset of proc specific features. By and large, code written for either proc will run on the other (again, provided that you don't use proc specific features). Cross platform would mean the same code being able to be compiled on MANY differing platforms. For example, you write a console app in plain ol' ANSI C or C++, you could compile it to run on x86 and recompile it to run on a PowerPC. That is cross platform. You can't do the same with ASM.

As you can see, ASM affords you MORE restrictions than C++.

I'd recommend grabbing Randel Hyde's "The Art of Assembly" if you'd like to start learning since it's freely available (google it). You'll want the 32-bit edition.

Hope this was somewhat helpful. It's probably cryptic since I'm still half asleep here. Guess I'll go get some friggin' coffee! :-)

Specifically I was thinking that Unix systems are often different hardware than Windows. Though there are some intel Unix machines, many are SPARC and MIPS machines. Also Mac OS obviously runs on different machines than any of these.

While there is some difference between OSes, most assembly code will still be protable between Windows and Unix on an x86. only things to watch out for wuld bel aoding external (OS specific) libraries or interrupts, if you rewrite those parts for each machine everything should work nicely. You also could research combining assembly with C/C++ so you can just write perforamnce critical parts in assembly without having to do the rest of the work keeping portability and just plain writing loads of low level code.

As for programs being in assemlby, programs are actually stored in machine code, assembly lnaguage isbasically machine code using words instead of hex digits so humans can read it more easily.

Was just a for instance since I think that's what abeylin was trying to convey.

Isn't it wonderful how in my post I forgot to mention differing OS' as well in my cross-platform junk? Jeez, shouldn't post when still waking up.

Quote:Original post by Kelly G
Specifically I was thinking that Unix systems are often different hardware than Windows. Though there are some intel Unix machines, many are SPARC and MIPS machines. Also Mac OS obviously runs on different machines than any of these.

In my experiance as a Linux user I've found the vast majority of Unixers run on x86 PCs. Now I guess it's being overtaken by OSX, but it's still much more common to find Unix on an Intel platform than most others.

Quote:Original post by Cherez
Now I guess it's being overtaken by OSX...

Only if you're counting people that don't know what a csh prompt is as Unix users. :-) Most OS X users wouldn't know what the shell was if it bit 'em on the rear.

EDIT: Was a little too general on OSX users. Some of them actually do know what it's all about and use it, just not the same quantity as Linux/BSD users since they normally installed it for the purpose of using a Unix type system.

I was using the broad definition of a Unixer as one whose computer runs a form of Unix.