Commit c4b60612 authored by Kunshan Wang's avatar Kunshan Wang

Explain CCALL type params using SYSCALL exmple

The CCALL instruction's design allows not only untraced function
pointers as the callee, but also allow system calls and so on. The
separation of "callee type" and "callee signature" -- where the callee
type is usually just `ufunctpr<sig>` -- may cause some confusion.
parent 861882cb
......@@ -2342,7 +2342,12 @@ The ``CCALL`` instruction calls a native function.
The *callee* must have type *T*. The allowed type of ``T``, and the number of
return values, are implementation-dependent and calling convention-dependent.
See `<native-interface.rst>`__ for a detailed description of the native interface.
NOTE: *T* is usually ``ufuncptr<sig>``, but the design also allows *T* to be
the system call number (integer) or anything meaningful for a particular
implementation.
See `<native-interface.rst>`__ for a detailed description of the native
interface.
The return values of ``CCALL`` are the return values of the native callee.
......@@ -2445,6 +2450,16 @@ or it receives the exception provided by the rebinding process.
// can move the object again.
COMMINST @uvm.native.unpin <@irefi8> %v
..
Example 2: If a Mu implementation supports directly making system calls (not
required nor recommended, but is implement-able), it can use the system call
number as the callee::
.const @sys_write <@i64> = 1 // The syscall number for Linux
%bytes_written = CCALL #SYSCALL <@i64 @write_sig> @sys_write (@FD %bufptr_pv @ARY_SZ)
Thread and Stack
================
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment