NASM Forum > Example Code

Source and Compiled Level Portability


pretty sure you already have your concrete concepts about the title already. but i just wanna impart my opinion about those coz there are notion and stereotypes about assembly language being not portable.

and the definition of that was true when the nascent computer hobbyist scene are bombarded with different chips. and with that, programmers had to write assembly language FOR each chip that are remotely similar to each other.

and then the sorcery of high level languages appeared (but that's for another thread).

so source level portability in assembly language.

pretty much the chips are collated now into a similarity and commonality. assembly instruction are still the same (unless it's arm & arm64). and this is even facilitated by the existence of old libraries that existed since brian kernighan wrote the hello world c program.

so in my opinion, source code portabilty is when you get a source, assemble it successfully in an operating system, mod the source by 1% or even .5% and then assemble it successfully in another operating system.

the same codebase being assembled in operating systems running under a similar or compatible hardware/chip.

this, again, is possible if you use libraries, not for the whole functionality of your code, but for certain functions (which were interrupts in DOS) that is present in the operating systems that you're building on.

coz int 0x80 or something like that is not ExitProcess() @ source level, right? (you get the point).

And compiled level portability??

you get a virtual machine/framework, write programs to run solely under the virtual machine's or framework constraints, develop ports of that virtual machine/framework to all of the available OS's and install those ports and the programs written for the virtual machine/framework will run in all architectures. and by all architectures i mean the different hardware on the bottom of the OS's that you want your virtual machine/framework to be installed in.

i think that the original .NET Framework's vision was to use old computers and mainframes coz they'll just make a .NET framework for 16 bit Computers or Mainframes and run C# or Visual Basic.NET programs in 16-bit Computers or Mainframes right?

~~ alCoPaUL [GIMO][As][aBrA][NPA][b8][BCVG][rRlf]

I don't understand your point? Nobody expects assembly code to be easily ported between different platforms (OS or hardware).


assembly language is not portable for say an x86 code to be ported to arm or powerpc or etc in terms of reusing most of the code. source level portability is doable coz windows, mac, unix, linux mostly run on x86 architecture and a single code base is not totally rewritten and compiled for each OS's is possible.

and add to that the C/C++ libraries that are installed in almost all OS coz everyone writes in C/C++. good thing that routines from these libraries are exposed to be used in the low level.

these omnipresent libraries are like the proto-virtual machines/frameworks that we all see now..

i hope i got my point across..

also about installing a ".NET Framework" or something similar on 16-bit computers and mainframes is not far fetched coz if you remember, the Itanium processor was totally emulated in Windows 98 computers in its early stages (and then they kinda cleaned it up like nothing happened but interestingly, the HP-UX system with IA-64 (Itanium) processor is listed as UNIX in the Single UNIX Specification along with the MacOS that got the x86_64 system under the UNIX 03 classification)


[0] Message Index

Go to full version