直接调用/跳转的形式是：
call / jmp selector:offset
这里的 selector 是 code segment selector 直接使用 selector 来索引 code segment，这将引发 CS 的改变，code segment descriptor 最终会被加载到 CS 寄存器里。
在 code segment descriptor 加载到 CS 之前，processor 会进行一系列的检查，包括权限检查、type 检查、limit 检查等，在通过检查后，processor 才加载 descriptor 到 CS，紧接着 eip = CS.base + offset，最后跳转到 cs:eip 执行。
以下面的指令为例：
(1) call 0x20:0x00040000
(2) jmp 0x20:0x00040000
0x20 是目标 code segment selector ，看看 processor 如何处理。
１、索引 code segment descriptor selector：0x20 的 RPL = 00，TI = 0，SI = 4
processor 在 GDT 以 SI = 4 索引查找 descriptor，当查找到 descriptor，processor 将判断这个 descriptor 的 types 是什么，再做进一步的处理。
这个查找 descriptor 的过程表述如下：
RPL = 00;
TI = 0;
SI = 4;
if (TI == 0)
DT = GDT; /* 在 GDT 表 */
else
DT = LDT; /* 在 LDT 表 */
temp_descriptor = DT.base + SI * 8; /* 获取 descriptor */
switch (temp_descriptor.type)
{
case CODE_DESC: /* 是个 code segment descriptor */
goto do_code_desc;
case CALL_GATE: /* 是个 call gate descriptor */
goto do_call_gate;
case TSS_DESC: /* 是个 TSS descriptor */
goto do_tss_desc;
case TASK_GATE: /* 是个 task gate descriptor */
goto do_task_gate;
default: /* 若不是上述几种类型，则产生 #GP 异常 */
goto do_#GP_exception;
}; |
processor 在判断 descriptor 后作进一步处理，这里假设 descriptor 是 code segment descriptor，下一步是 processor 将作权限的检查，检查程序是否有权限访问目标 code segment。
在上述获取 descriptor 之前，processor 还会对 GDT 的 limit 作检测，若发现 GDT.base + SI * 8 > GDT.limit 同样会引发 #GP 异常。这种情况也就是说：索引值越界了。
2、权限 check processor 用当前的权限与目标 code segment descriptor 作的权限 check。当前的权限就是 RPL & CPL。在这直接调用/跳转目标 code segment 的 check 中 conforming 与 nonconforming 类型的 descriptor 有着很大的区别。
这个权限的 check 表述如下：
DPL = temp_descriptor.DPL;
if (temp_descriptor.C == 0) { /* code segment 是 non-conforming 类型 */
if (CPL == DPL) {
if (RPL <= DPL) {
goto do_next; /* 通过检查，允许访问 */
} else
goto do_#GP_exception;
} else
goto do_#GP_exception; /* 产生 #GP 异常 */
} else { /* code segment 是 conforming 类型 */
if (CPL >= DPL) {
goto do_next; /* 通过检查，允许访问 */
} else
goto do_#GP_exception; /* 产生 #GP 异常 */
} |
当 code segment 是 non-conforming 类型时，需要
CPL == DPL && RPL <= DPL 才能通过。
当 code segment 是 conforming 类型时，仅需要
CPL >= DPL 就能通过了。
当 code segment 是 conforming 类型时，CPL >= DPL，表示当前的代码可以向高权限级别跳转。这里无需判断 RPL 权限。
假设当前运行在 3 级代码上，通过 call / jmp 到 conforming 类型的 0 级别代码时，当前的 CPL 依然是 3 级。因为在直接 call/jmp 目标 code segment 这种调用方式上，是不会改变当前的运行级别。
情景提示：
在直接 call/jmp 目标 code segment 方式上，CPL 是不会改变的。既使由低权限代码调用高权限的 conforming 类型的代码，CPL 也不会改变。
在由低权限直接 call/jmp 高权限的代码仅限于 conforming 类型的 code segment。 |
conforming 类型的 code segment 允许低权限的代码向高权限的这类代码调用/跳转，而 non-conforming 则不允许直接调用/跳转。直接 call/jmp 目标 code segment 不改变 CPL，基于这个原因 non-conforming 类型的 code segment 必须要 CPL == DPL。
若要向高权限的 non-conforming 类型 code segment 调用/跳转时，必须通过 call gate 进行 call / jmp。3、加载 descriptor 通过上述权限检查后，processor 会将目标的 selector 加载到 CS 寄存器中，而 descriptor 也会加载到 CS 寄存中。
加载 descriptor 过程表述为：
selector = selector | (SI << 3) | (TI << 2) | CS.selector.DPL;
CS.selector = selector; /* 加载 selector */
CS.base = temp_descriptor.base; /* 加载 base 进入 CS*/
CS.limit = temp_descriptor.limit; /* 加载 limit 进入 CS */
CS.attribute = temp_descriptor.attribute; /* 加载 attribute 进入 CS */ |
selector = selector | (SI << 3) | (TI << 2) | CS.selector.DPL;
-----------------------------------------------------------
在这一步里，使用目标 code segment selector 的 SI 更新 CS.selector.SI，使用 TI 更新 CS.selector.TI。
但是这里不更新 CS.selector.DPL，因为 CPL 不会改变。 CS 内的信息（selector & descriptor）会保持下去，直至下一次重新加载 descriptor 到 CS 为止。所以，在同一 code segment 内的 call/jmp 是不会做权限检查等等。
4、执行目标 code segment processor 会加载 CS.base + offset 进入 eip ，然后执行 CS: eip 处的代码。这个 offset 就是 call/jmp 指令的 eip 值，也就是上述的 0x00040000 值。
push old_cs;
push old_eip;
eip = CS.base + offset; /* 加载 eip */
(void (*)()) &eip; /* 执行 cs: eip */ |
由于这里不会改变 CPL，所以也无需做检测是否需要 stack 切换的工作。
7.1.3.2.1、 long mode 的 64 bit 模式下的直接 call / jmp 在 64 bit 模式下不支持 call/jmp selector:offset 这种指令形式，在 64 bit 模式下，这种形式将引发 #UD 异常。
在 64 bit 模式下仅支持：
call far ptr [target_code]
或
jmp far ptr [target_code]
---------------------------------------
仅支持目标是内存操作数的指令形式。当然这个内存操作数可以是任一种内存寻址模式。
如：
call far ptr [rax+rcx*8+0xc]
call far ptr [rip+0x80140]
指令从 [target_code] 中取出 32 位的 offset 和 16 位 selector。 32 位的 offset 被零扩展至 64 位再加上 rip。
情景提示：
Intel 明确说明： call far ptr [target_code]，在 [target_code] 中可以直接读取 64 位的 offset 值和 16 位 selector 值。当编译机器码为：48 ff /3 时可以支持 64 位 offset 值 + 16 位 selector。
AMD 则明确说明：当 operands 为 64 位时，读取的仅是 32 位的 offset 值 + 16 位的 selector，32 位的 offset 将零扩展至 64 位的 offset。
|
情景提示：
Intel 说的是在指令编码中使用 REX.W 将 operands 扩展为 64 位，则读取的是 64 位 offset。AMD 的文档中没有说明当使用 REX.W 将 operands 扩展为 64 位时 call far 指令将会读取多少？
但是，在调试器 x64 版的 windbg 里实验表明：使用 REX.W 确实可以将 call far 指令扩展为读取 64 位 offset + 16 位的 selector 。
|
processor 的处理过程：
１、索引 code segment descriptor 的方法和 x86 的一致。但和 x86 下不同的是： (1)、64 bit 下不存在 task gate
(2)、若使用 selector 查找到的 descriptor 是 TSS descriptor 将产生 #GP 异常。
(3)、64 bit 下不进行 limit 的 check。
(4)、64 bit 下 processor 将检测 code segment descriptor 的 L = 1 && D = 0，表明目标代码是 64 位代码，若 L = 0 或者 D = 1 则产生 #GP 异常２、权限的 check 64 bit 的权限 check 和 x86 的一致，即：
if (non-conforming == 1) { /* 是 non-conforming 类型 */
if ( CPL == DPL && RPL <= DPL)
/* 通过，允许访问 */
else
/* 失败，拒绝访问，产生 #GP 异常 */
} else { /* 是 conforming 类型 */
if (CPL >= DPL)
/* 通过，允许访问 */
else
/* 失败，拒绝访问，产生 #GP 异常 */
}
|
３、加载 descriptor 进入 CS 由于 64 bit 模式下，code segment descriptor 中仅 L、D、DPL、C 及 P 属性有效，其它都无效的，这一步意义不大。CS.base 和 CS.limit 都是无效的。base 被强制为 0，limit 是固定的 64 位空间。
代替的是进行 canonical-address 地址检查。
此时，CPL 也不会改变，即：CS.selector.DPL 不会被更新。所以也不会引发 stack 切换。
４、执行 code segment 接下来 64 位的 offset 值被加到了 rip 寄存器中，然后执行 rip 处的指令。
