int80h vs syscall

Why does int 80h only work with certain code on x86_64 Linux?
for example:

section .bss
  arg    resq

section .text
  global _start

_start:
  ; code here to fill arg with argv[1]
  mov rax,1
  mov rdi,2
  mov rsi,[arg]
  mov rdx,[arglen]
  syscall

is fine, but

section .bss
  arg    resq

section .text
  global _start

_start:
  ; code here to fill arg with argv[1]
  mov rax,4
  mov rbx,2
  mov rcx,[arg]
  mov rdx,[arglen]
  int 80h
doesn't work with pointers copied from bss, if that's even relevant
rax is filled with 0xfffffffffffffff2, aka -14.

>>8
Those nops ar for alignment (mod4), look more carefully.
Notice that there's 2 exports?  KiFastSystemCall and KiFastSystemCallRet. Originally, I was confused about the nops too, but if you think about it, it makes perfect sense:
KiFastSystemCall is what you call from user mode and the kernel-mode handler returns/sets eip to KiFastSystemCallRet upon exiting the handler and returning to user mode. The nops are ther efor alignment, as all functions are aligned mod 4(can be a different value depending on options passed to the cl/link). The nops indicate that it was built in Release mode instead of Debug mode(if it was debug mode, you'd get 0xCC(int3)'s instead of nop(0x90)'s).

Those nops were slightly misleading when I first encountered them, as I used to step over the sysenter in a debugger which made the app continue. What I should have done is set a breakpoint on the return instead, or better yet, step over the call to KiFastSystemCall.

If one views the 2 exports as separate functions that they are, everything makes sense. KiFastSystemCall is a __naked function which probably looks something like:

DWORD __declspec(naked) __stdcall KiFastSystemCall(...)
{
     __asm
     {
          mov edx,esp
          sysenter
     }
}