The interesting thing about this particular asm code is that it will only run on 64-bit Intel and AMD microprocessors. It will not run on a 32-bit CPU. And it will not run on ARM, SPARC, or old iMac processors!

On the other hand, the print "Hello World"; perl equivalent of this program is not bound to one particular architecture or one particular OS. It would run on any CPU and any OS.

To further prove my point, if you would run an assembler to convert this asm text code to an obj file and then link the obj into exe file, it would result in a Windows executable. If you tried to run it in Linux, it wouldn't run (without wine). If you tried to execute it on an Apple MacBook Pro, it wouldn't run. It wouldn't run even if you included it in your perl script inline. This code is not only machine specific, but it is OS specific. That's what I meant. It's a fact. Try it if you don't believe me.

A simple print "Hello World" perl script will run on any computer, but once you insert asm code into your perl script as inline assembly, chances are you have limited your perl script to one particular processor and one particular OS! Now, your perl script is no longer compatible with 90% of other computers out there. But if you omit the inline assembly code, then it will run on other computers.

section .data
Message        db "Hello World", 0Dh, 0Ah
MessageLength  EQU $-Message

section .text
Start:
 sub   RSP, 8
 sub   RSP, 32
 mov   ECX, STD_OUTPUT_HANDLE
 call  GetStdHandle
 mov   qword [REL StandardHandle], RAX
 add   RSP, 32
 sub   RSP, 32 + 8 + 8
 mov   RCX, qword [REL StandardHandle]
 lea   RDX, [REL Message]
 mov   R8, MessageLength
 lea   R9, [REL Written]
 mov   qword [RSP + 4 * 8], NULL
 call  WriteFile
 add   RSP, 48
 xor   ECX, ECX
 call  ExitProcess
[download]

This code is not only machine specific, but it is OS specific.

Yes, you're right about that code being specific to an architecture and OS. However, I think the quibble here is that it's very different from what you originally said:

Assembly language is machine-specific, while perl is designed to run on any platform. If you write an assembly program for Linux, it won't run on DOS or Windows.

Stated so generally, that's not correct: some assembly programs can be run on multiple OSes. And I think "machine-specific" is too vague, as that could also be interpreted to mean that assembly code is specific to one particular computer; the Wikipedia quote you gave here is much more accurate. And some of your argumentation unfortunately goes against itself, like here:

... it would result in a Windows executable. If you tried to run it in Linux, it wouldn't run (without wine).

Wine Is Not an Emulator, and there's also the Windows Subsystem for Linux, which you may not have known about, but both these examples contradict your statement "... if you try to execute a Linux program in DOS or vice versa, it won't even load, because the OS does not recognize it as a valid executable." Yes, a compatibility layer is needed, but the assembly is executed natively. I also have to say I think you're muddying things between the concepts of ABI, assembly language, and actual binary processor instructions.

Another example: in this node you suggest that adding assembly to Perl will make it less portable, which is of course true across processor architectures, and it's true when comparing a Perl program with assembly to one without assembly. But in the same paragraph you mention portability across OSes, and here I'd say that using inline assembly in Perl can actually make the assembly more portable than the same assembly code without Perl. The same is true for assembly embedded in C code, which most if not all C compilers support. Take your initial example:

So, even if the program is designed to do a very simple task such as calculate the value of PI. No file access needed. No internet access needed. No libraries have to be loaded. Just do a bunch of calculations and print the result to the screen.

The only thing in that whole program that is OS-specific is the output part. If all the assembly had to do was return that value in memory to Perl instead, and Perl does the printing, then suddenly you have portability across all OSes on the same processor architecture (that Perl runs on; another point you gloss over in your various posts). See the example in the synopsis of Inline::ASM, for example.

Don't get me wrong, when it comes to 80386 assembly, I think you know your stuff. Rereading your posts here, I also understand the points you were trying to make. Here you said "You know what I am talking about," and yes, we know what you're talking about. But remember that this is all taken in the context of helping newcomers: making over-generalized statements, sometimes conflicting and/or inaccurate ones, can muddy the waters and cause confusion, and potentially be more damaging than helpful. I would suggest being more careful with the language you use to explain things.

Ok, I will try to be more precise next time.

I just had the feeling that the original poster was not familiar with assembly language at all. And I thought combinging perl with assembly is probably not where he should start. I mean, you can put assembly code in just about anywhere. You can insert it into C or C++. One can insert inline assembly even into BASIC if one is really determined. lol But I don't think these are the best or easiest ways to learn about assembly. I would call this the more advanced stuff. So, if I just started learning about assembly, then combining languages is not where I would start.

You bound this to windows by using things WriteFile, did you made a copy/paste error because you don't import (extern) the Windows API functions (WriteFile, GetStdHandle or ExitProcess). If you write OS specific code obviously it will only work on that OS. Assembly can be used to create a 'hello world' for any CPU, regardless of OS. You could write perl code which will only work on certain OS. Assembly can run on a bare CPU, stated many times in the thread, stop talking round this. You make it sound like your way is the only way, and the right way, buddy it's not. These are bad habits, arguing against yourself, contradicting yourself, detailing threads, confusing OP by changing the terminology in different posts.