path: root/doc/src/libmcpu-architecture-core-ru.tex

\section{Адресные пространства}
LibMCPU имеет независимые архитектурные адресные пространства (address spaces). Register file остаётся TLS-состоянием CPU; PROGRAM содержит исполняемый код; остальные сегменты являются пространствами объектов данных (data-object spaces) и используют целевое представление объектов LibMPU.

\begin{center}
\begin{tabularx}{0.99\textwidth}{@{}L{21mm}L{15mm}L{81mm}Y@{}}
\toprule
\textbf{Пространство} & \textbf{SEG} & \textbf{Назначение} & \textbf{Доступ guest}\\
\midrule
DATA & 0x0 & Глобальные/статические объекты и полноразмерные константы & R/W\\
STACK & 0x1 & Вызовы, аргументы, automatic objects, spills & R/W\\
PROGRAM & 0x2 & Машинный код; секции \code{.init/.text/.fini} & R + execute; запись запрещена\\
CONTROL & 0x3 & Параметры управления запуском и модельным временем & R; runtime может изменять\\
INPUT & 0x4 & Внешние возмущающие воздействия & R; runtime задаёт значения\\
OUTPUT & 0x5 & Воздействие модели на среду / текущий выходной вектор & R/W\\
TRACE & 0x6 & Текущий telemetry frame модели & R/W\\
HEAP & 0x7 & Обнулённая runtime-область динамической памяти & R/W\\
reserved & 0x8..0xF & Будущие адресные пространства & dereference fault\\
Register file & -- & 512 KiB TLS; перекрывающиеся представления регистров & REG24\\
\bottomrule
\end{tabularx}
\end{center}

PROGRAM, DATA, STACK, CONTROL, INPUT, OUTPUT, TRACE и HEAP логически независимы и байтово адресуемы. Host backing каждого активного адресного пространства создаётся отдельным anonymous \code{mmap()}; файлы executable/image никогда не являются file-backed memory виртуального CPU.

DATA и HEAP разделены. DATA является статическим пространством данных, формируемым образом executable (image-backed data space). HEAP является отдельным runtime-пространством с SEG=0x7, не имеет assembler payload и не расширяет DATA. Будущие malloc/free/realloc/calloc будут library-level ABI поверх HEAP, а не ISA instructions.

Структуры CONTROL/INPUT/OUTPUT/TRACE не задаются CPU. ISA видит только bytes и права доступа. Форматы записей модели (model records), имена полей, типы и семантику модельного времени определит будущий C-подобный язык моделирования и runtime metadata.

\begin{figure}[ht]
\centering
\begin{tikzpicture}[font=\sffamily\small,node distance=7mm and 8mm]
  \node[draw=McpuBlue,fill=McpuGrayBg,minimum width=31mm,minimum height=12mm,align=center] (d) {DATA 0x0\\{\scriptsize R/W}};
  \node[draw=McpuBlue,fill=McpuGrayBg,right=of d,minimum width=31mm,minimum height=12mm,align=center] (s) {STACK 0x1\\{\scriptsize R/W}};
  \node[draw=McpuBlue,fill=McpuGreenBg,right=of s,minimum width=31mm,minimum height=12mm,align=center] (p) {PROGRAM 0x2\\{\scriptsize R + execute}};
  \node[draw=McpuBlue,fill=McpuGrayBg,right=of p,minimum width=31mm,minimum height=12mm,align=center] (c) {CONTROL 0x3\\{\scriptsize read-only}};
  \node[draw=McpuBlue,fill=McpuGrayBg,below=of d,minimum width=31mm,minimum height=12mm,align=center] (i) {INPUT 0x4\\{\scriptsize read-only}};
  \node[draw=McpuBlue,fill=McpuGrayBg,right=of i,minimum width=31mm,minimum height=12mm,align=center] (o) {OUTPUT 0x5\\{\scriptsize R/W}};
  \node[draw=McpuBlue,fill=McpuGrayBg,right=of o,minimum width=31mm,minimum height=12mm,align=center] (t) {TRACE 0x6\\{\scriptsize R/W}};
  \node[draw=McpuBlue,fill=McpuGrayBg,right=of t,minimum width=31mm,minimum height=12mm,align=center] (h) {HEAP 0x7\\{\scriptsize R/W}};
  \node[draw=McpuBlue2,dashed,fill=white,below=9mm of $(o)!0.5!(t)$,minimum width=70mm,minimum height=9mm] {0x8..0xF зарезервированы; разыменование запрещено};
\end{tikzpicture}
\caption{Активная карта сегментов PTR64 и права доступа guest-программы.}
\end{figure}

\section{Физическая адресация регистра: REG24}
Машинный операнд физического регистра имеет ровно 24 бита. Четыре старших бита кодируют физическую ширину представления регистра, оставшиеся двадцать --- байтовый адрес начала представления внутри единого регистрового файла.

\begin{figure}[ht]
\centering
\begin{tikzpicture}[font=\sffamily\small,x=0.31cm,y=0.78cm]
  \draw[fill=McpuGreenBg] (0,0) rectangle (4,1);
  \draw[fill=McpuBlueBg] (4,0) rectangle (24,1);
  \node at (2,0.5) {WIDTH};
  \node at (14,0.5) {BYTE ADDRESS};
  \node[above] at (2,1) {bits 23..20};
  \node[above] at (14,1) {bits 19..0};
  \draw[decorate,decoration={brace,mirror,amplitude=4pt}] (0,-0.18) -- (24,-0.18);
  \node[below=6pt] at (12,-0.18) {REG24 = 3 bytes в PROGRAM};
\end{tikzpicture}
\caption{Логическое устройство REG24.}
\end{figure}

Три байта PROGRAM формируются следующим образом: первый байт содержит \code{WIDTH[3:0]} и \code{ADDRESS[19:16]}, второй --- \code{ADDRESS[15:8]}, третий --- \code{ADDRESS[7:0]}. Это машинное поле имеет канонический порядок байтов PROGRAM и не является host C bit-field.

\begin{center}
\begin{tabularx}{0.78\textwidth}{@{}L{22mm}L{38mm}Y@{}}
\toprule
\textbf{WIDTH} & \textbf{Физическая ширина} & \textbf{Размер}\\
\midrule
0x0 & 8 bit & 1 byte\\
0x1 & 16 bit & 2 bytes\\
0x2 & 32 bit & 4 bytes\\
0x3 & 64 bit & 8 bytes\\
0x4 & 128 bit & 16 bytes\\
0x5 & 256 bit & 32 bytes\\
0x6 & 512 bit & 64 bytes\\
0x7 & 1024 bit & 128 bytes\\
0x8 & 2048 bit & 256 bytes\\
0x9 & 4096 bit & 512 bytes\\
0xA & 8192 bit & 1024 bytes\\
0xB & 16384 bit & 2048 bytes\\
0xC & 32768 bit & 4096 bytes\\
0xD & 65536 bit & 8192 bytes\\
\bottomrule
\end{tabularx}
\end{center}

Register file имеет 512 KiB, поэтому ADDRESS[19] обязан быть нулём. Views имеют natural alignment. Формула архитектуры остаётся REGISTER = WIDTH + BYTE ADDRESS.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 r8@0x00000       -> 00 00 00
 r16@0x00000      -> 10 00 00
 r4096@0x02000    -> 90 20 00
 r65536@0x7e000   -> D7 E0 00
\end{lstlisting}

\begin{figure}[ht]
\centering
\begin{tikzpicture}[font=\sffamily\small,>=Latex,x=0.92cm,y=0.85cm]
  \foreach \x in {0,...,7} {
    \draw (\x,0) rectangle ++(1,0.75);
    \node[font=\ttfamily\scriptsize] at (\x+0.5,0.375) {+\x};
  }
  \draw[very thick,color=McpuBlue] (0,-0.18) rectangle (8,0.93);
  \node[anchor=east,color=McpuBlue] at (-0.15,0.38) {\texttt{r64@0x100}};
  \draw[very thick,color=McpuGreen] (4,-0.35) rectangle (8,1.10);
  \node[anchor=west,color=McpuGreen] at (8.15,0.38) {\texttt{r32@0x104}};
  \node[below=5mm] at (4,0) {одни и те же физические байты register file};
\end{tikzpicture}
\caption{Представления (views) разной ширины могут перекрываться.}
\end{figure}

\section{r и c: разные смыслы одного REG24}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 r64@0x02000    ; 64 физических бита, integer/real смысл задаёт opcode
 c64@0x02000    ; те же 64 физических бита, complex semantic view
\end{lstlisting}

Обе записи имеют одинаковый REG24. Для c<bits> число bits означает полную физическую ширину; каждая real-компонента имеет половинную ширину.

\begin{center}
\begin{tabularx}{0.78\textwidth}{@{}L{34mm}L{38mm}Y@{}}
\toprule
\textbf{Complex view} & \textbf{Физический размер} & \textbf{Компоненты}\\
\midrule
\code{c64} & 64 bit & 2 x real32\\
\code{c128} & 128 bit & 2 x real64\\
\code{c4096} & 4096 bit & 2 x real2048\\
\code{c32768} & 32768 bit & 2 x real16384\\
\code{c65536} & 65536 bit & 2 x real32768\\
\bottomrule
\end{tabularx}
\end{center}

\section{Канонический порядок байтов PROGRAM}
OPCODE16, REG24, IMM64, ADDR64, CODE64 и OFF64 кодируются в PROGRAM MSB-first, независимо от host endian и target data profile. Архитектурные data objects (register file, DATA, STACK и остальные data spaces) образуют отдельный byte-order domain и используют representation, совместимое с настроенной LibMPU. Полная нормативная модель приведена в разделе 31.

PROGRAM serialization и architectural data-object representation - разные уровни. Decoder собирает многобайтовые поля явно как MSB-first; произвольный host-cast packed C-структурой не является частью формата.

\section{Непосредственные числовые константы}
Inline numeric payload всегда равен 64 битам; opcode задаёт интерпретацию. Непосредственная форма предназначена только для значений, которые точно представимы в машинном immediate-формате соответствующей инструкции. Ассемблер не имеет права молча терять значащие биты/цифры при преобразовании textual literal в immediate.

Exact-immediate rule. Если textual literal не представим точно в immediate source format,

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
  mcpu-as завершает сборку с ошибкой и рекомендует создать полноразмерный объект
\end{lstlisting}

через .integer/.real/.complex в DATA и загрузить его инструкцией LOAD.

\subsection{LDI - Integer}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 LDI r<bits>@addr, integer
\end{lstlisting}

OPCODE16 + REG24 + IMM64 = 13 bytes

IMM64 - signed 64-bit two's-complement integer. Для destination шириной 64 бит и более literal обязан точно помещаться в signed integer64. Для destination уже 64 бит literal дополнительно обязан помещаться в signed диапазон именно этой ширины: assembler не генерирует заведомо теряющее значение icvt().

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; корректно
 LDI r8@0x00000,   -1
 LDI r32@0x00010, 1000000
 LDI r4096@0x00100, 9223372036854775807

 ; ошибка: +255 не является signed integer8 value
 LDI r8@0x00000, 255

 ; ошибка: literal шире signed integer64 source format
 LDI r128@0x00100, 9223372036854775808
\end{lstlisting}

Для большого целого используется DATA:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 .data
 .align 16
\end{lstlisting}

wide\_integer:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
         .integer 128, 9223372036854775808
 .text
         LOAD r128@0x00100, wide_integer
\end{lstlisting}

Типичная диагностика:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 mcpu-as: error:
 line N: LDI immediate is not exactly representable as integer64;
\end{lstlisting}

use .integer <bits>, value in DATA and LOAD

\subsection{LDR - Real}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 LDR r32@0x02000,   -17.0
 LDR r4096@0x04000, 2.0
\end{lstlisting}

OPCODE16 + REG24 + REAL64 = 13 bytes

Machine payload LDR всегда binary64. Но assembler применяет более строгую проверку в зависимости от destination: для r32 textual literal обязан быть точно представим как real32; для r64 и всех более широких Real-register views - точно представим как real64. После этой проверки runtime по-прежнему выполняет r\_cvt() из embedded real64 к физической ширине destination.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; корректно: значения точно представимы
 LDR r32@0x02000,   -17.0
 LDR r4096@0x04000, 2.0

 ; ошибка: 0.1 не имеет точного binary32 representation
 LDR r32@0x02000, 0.1

 ; ошибка: high-precision decimal сначала потерял бы точность в binary64
 LDR r4096@0x04000, 3.14243987129849274029174912694696912849214e-286
\end{lstlisting}

Диагностика для r32:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 mcpu-as: error:
 line N: LDR immediate is not exactly representable as real32;
\end{lstlisting}

use .real <bits>, value in DATA and LOAD

Диагностика для r64 и шире:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 mcpu-as: error:
 line N: LDR immediate is not exactly representable as real64;
\end{lstlisting}

use .real <bits>, value in DATA and LOAD

Правильная форма для произвольной высокоточной константы:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 .data
 .align 16
\end{lstlisting}

pi\_like:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
          .real 4096, 3.14243987129849274029174912694696912849214e-286
 .text
          LOAD r4096@0x04000, pi_like
\end{lstlisting}

.real передаёт textual literal непосредственно ascii\_to\_real() LibMPU с precision конечного DATA-object; промежуточного binary64 здесь нет.

\subsection{LDC - Complex}
В машинном коде inline-комплекс состоит из двух компонент binary32:
\begin{center}
\begin{tabularx}{0.72\textwidth}{@{}Y Y@{}}
\toprule
\textbf{REAL} & \textbf{IMAG}\\
\midrule
float32, 32 bits & float32, 32 bits\\
\bottomrule
\end{tabularx}
\end{center}

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 LDC c64@0x02000,   -17.0r0+32.0j0
 LDC c4096@0x04000, 2.0r0-0.5j0
\end{lstlisting}

Формат инструкции: OPCODE16 + REG24 + COMPLEX64 = 13 bytes.

Минимальный complex destination - c64, то есть две real32 components. Inline LDC всегда содержит 2 x binary32, поэтому каждая textual component обязана быть точно представима как real32 независимо от ширины destination. После декодирования CPU расширяет обе real32 components через LibMPU к половине физической ширины c-view и вызывает c\_gen\_complex().

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; корректно
 LDC c64@0x02000, -17.0r0+32.0j0
 LDC c4096@0x04000, 2.0r0-0.5j0

 ; ошибка: real component 0.1 не представима точно как real32
 LDC c128@0x02000, 0.1r0+32.0j0

 ; ошибка ещё на разборе регистра: c32 запрещён
 LDC c32@0x02000, 1.0r0+2.0j0
\end{lstlisting}

Диагностика потери точности:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 mcpu-as: error:
 line N: LDC immediate component is not exactly representable as real32;
\end{lstlisting}

use .complex <bits>, real, imag in DATA and LOAD

Для широкого complex object:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 .data
 .align 16
\end{lstlisting}

wide\_z:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
         .complex 4096, 3.14243987129849274029174912694696912849214e-286, -0.125
 .text
         LOAD c4096@0x04000, wide_z
\end{lstlisting}

.complex формирует components непосредственно в требуемой LibMPU precision; LDC для таких значений использовать нельзя.

\subsection{Почему это assembler error, а не runtime rounding}
Immediate является частью PROGRAM image и уже после сборки не содержит исходный текст literal. Если assembler сначала округлит длинную десятичную запись до binary64/binary32, executor уже не способен узнать, что информация была потеряна. Поэтому exactness проверяется до emission bytecode: textual literal разбирается LibMPU с высокой precision, конвертируется в immediate precision и обратно, после чего значения сравниваются. Только exact round-trip допускается к emission.

Это правило относится к immediate-формам LDI/LDR/LDC. Полноразмерные DATA directives намеренно выполняют conversion непосредственно к объявленной ширине объекта; обычное математическое округление decimal->binary в этой целевой precision является частью создания самого объекта.

\subsection{Conversion-class instructions сохраняют PSW}
Некоторые LibMPU conversion helpers изменяют внутренние arithmetic/status flags как побочный эффект своей реализации. Например, icvt() влияет на часть integer flags. Для LibMCPU это нежелательно: преобразование значения не должно неожиданно уничтожать condition state, вычисленное предыдущей инструкцией.

Нормативное правило. Инструкции LDI, LDR, LDC, ICVT, RCVT, ITOR, UITOR, RTOI, RTOUI, CCVT и CRTOC являются PSW-neutral. Перед вызовом LibMPU conversion routine executor сохраняет PSW[15:0], после завершения conversion восстанавливает прежнее значение. HF/TF/IF/MODE при этом вообще не изменяются.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 saved = PSW[15:0]
 icvt(...)           ; или r_cvt(), c_cvt(), ltor(), ...
\end{lstlisting}

PSW[15:0] = saved

Внутренняя реализация LibMCPU намеренно не включает private header LibMPU и не зависит от private macro \_\_MPU\_FLAGS. Сохранение/восстановление делается через уже существующий public PSW facade LibMCPU, который собирает и восстанавливает LibMPU flags через публичные accessor functions. Архитектурно результат эквивалентен сохранению \_\_MPU\_FLAGS вокруг conversion.

Это правило относится только к операциям, смысл которых - загрузить или преобразовать значение. Обычные arithmetic instructions продолжают публиковать нормальные LibMPU flag effects и поэтому не выполняют такого save/restore.

\section{DATA, ADDR64 и NULL guard}
ADDR64 остаётся 64-битным byte offset внутри DATA для прямых инструкций LOAD/STORE. Это не PTR64.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 LOAD REG24, ADDR64          ; DATA -> register file
 STORE ADDR64, REG24         ; register file -> DATA
\end{lstlisting}

Обе формы занимают 13 байт. Размер копии задаётся физической шириной REG24.

\subsection{Нулевой PTR64 и первые 16 байт DATA}
ABI определяет нулевой указатель как ровно 0x0000000000000000. Битово это совпадает с комбинацией SEG=DATA, OFFSET=0. Поэтому executor отдельно распознаёт all-zero PTR64; при попытке разыменования LOADP, STOREP, BMOV и BMOVI возвращают CPU\_EXEC\_POINTER\_FAULT.

PTR64 NULL = 0x0000000000000000

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 DATA 0x0000 .. 0x000f     reserved NULL guard
 DATA 0x0010 ..             ordinary assembler objects
\end{lstlisting}

Assembler всегда начинает DATA image с 16 нулевых guard bytes. Поэтому обычная DATA label не может иметь PTR64 value zero и первый допустимый object offset сразу кратен 16.

Прямой ADDR64 и NULL. NULL относится к PTR64. Низкоуровневые прямые LOAD/STORE технически адресуют DATA по raw ADDR64, но ABI считает DATA[0..15] зарезервированной областью и conforming assembler/program не размещает там объекты.

\subsection{.align выравнивает guest offset}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 .data
 .align 16
\end{lstlisting}

x:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
         .real 4096, 0.0
\end{lstlisting}

.align N двигает только текущий guest DATA offset до следующего кратного N значения. Директивы .integer/.real/.complex сами по себе не вставляют никакого padding и пишут

объект точно с текущего offset. Это принципиально: assembler способен описывать как обычные ABI-layouts, так и packed binary layouts.

\subsection{Code pointers in DATA}
DATA может содержать PROGRAM pointers для indirect control flow. Директива .cptr label занимает 8 байт, резервирует PTR64 object и после полной сборки .text разрешает CODE label в PROGRAM byte offset. Она не добавляет implicit alignment.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 .data
 .align 8
\end{lstlisting}

handlers:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
          .cptr handler0
          .cptr handler1
\end{lstlisting}

Получившийся object можно загрузить обычным LOADP r64,... и передать в JMPP/CALLP. Forward CODE labels поддерживаются assembler fixup mechanism.

\section{Полноразмерные константы}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 .data
 .align 16
\end{lstlisting}

huge\_integer:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
         .integer 65536, 12345678901234567890...
\end{lstlisting}

high\_precision\_real:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
         .real 16384, 1.234567890123456789...
\end{lstlisting}

high\_precision\_complex:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
         .complex 32768, 1.234567890123456789..., -2.5

 .text
         LOAD r65536@0x00000, huge_integer
         LOAD r16384@0x02000, high_precision_real
         LOAD c32768@0x08000, high_precision_complex
\end{lstlisting}

Тип, размер, internal padding/alignment C-like объектов известны assembler/compiler. CPU копирует байты и не хранит runtime type tag.

\section{Предопределённые математические константы}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 RCONST r4096@0x02000, PI
 RCONST r16384@0x04000, E
 RCONST r128@0x08000, SQRT2
\end{lstlisting}

OPCODE16 + REG24 + CONST8 = 6 bytes

LibMPU строит значение непосредственно с требуемой точностью. Основные группы констант перечислены в приложении: ZERO/HALF/ONE/TWO/TEN, PI/E/LN2/LN10, кратные PI, SQRT2/SQRT3/SQRTPI, GOLDENRATIO, EULERGAMMA и CATALAN.

\section{OPCODE16 и сигнатуры}
OPCODE16 полностью определяет количество и тип следующих операндов. Отдельного format-byte нет.

\begin{center}
\begin{tabularx}{0.96\textwidth}{@{}L{22mm}L{52mm}Y@{}}
\toprule
\textbf{Диапазон} & \textbf{Назначение} & \textbf{Примеры}\\
\midrule
0x00xx & CPU/system и PSW status & NOP, HALT, SETF/CLRF, CLRCPUF/CLRMPUF\\
0x01xx & data movement / построение адресов & MOV, LDI, LDR, LDC, LOAD, STORE, LEA, LEASP, LOADP, STOREP\\
0x10xx & integer & IADD, ISUB, ICMP, ...\\
0x20xx & real & RADD, RSIN, RLOG, ...\\
0x30xx & complex & CADD, CEXP, CPOW, ...\\
0x40xx & control flow & JMP/JMPP, JSET/JCLR, CALL/CALLP, RET\\
0x50xx & stack/frame & PUSH, POP, LDSP, STSP, ADJSP, PUSHFP, SETFP, ...\\
\bottomrule
\end{tabularx}
\end{center}

\begin{longtable}{@{}L{23mm}L{30mm}L{105mm}@{}}
\toprule
\textbf{Код операции} & \textbf{Мнемоника} & \textbf{Формат операндов}\\
\midrule
\endfirsthead
\toprule
\textbf{Код операции} & \textbf{Мнемоника} & \textbf{Формат операндов}\\
\midrule
\endhead
0x0010 & SETF & PSWBIT8 (AF..INXF)\\
0x0011 & CLRF & PSWBIT8 (AF..INXF)\\
0x0012 & CLRCPUF & ---\\
0x0013 & CLRMPUF & ---\\
0x0120 & LOAD & R/C, ADDR64\\
0x0121 & STORE & ADDR64, R/C\\
0x0130 & LEA & r64, ADDR64\\
0x0131 & LEASP & r64, OFF64\\
0x0132 & LOADP & R/C, r64(PTR64)\\
0x0133 & STOREP & r64(PTR64), R/C\\
0x0140 & PADD & r64(dst), r64(ptr), r64(delta)\\
0x0141 & PADDI & r64(dst), r64(ptr), OFF64\\
0x0142 & PSUB & r64(dst), r64(ptr), r64(delta)\\
0x0143 & PSUBI & r64(dst), r64(ptr), OFF64\\
0x0144 & PDIFF & r64(dst), r64(ptr1), r64(ptr2)\\
0x0150 & BMOV & r64(dst PTR64), r64(src PTR64), r64(byte_count)\\
0x0151 & BMOVI & r64(dst PTR64), r64(src PTR64), IMM64 byte_count\\
0x4000 & JMP & CODE64\\
0x4001/02 & JSET/JCLR & PSWBIT8, CODE64\\
0x4003 & JMPP & r64(PROGRAM PTR64)\\
0x4010 & CALL & CODE64\\
0x4011 & RET & ---\\
0x4012 & CALLP & r64(PROGRAM PTR64)\\
0x5000/01 & PUSH/POP & R/C\\
0x5010/11 & LDSP/STSP & R/C,OFF64 / OFF64,R/C\\
0x5020 & ADJSP & OFF64\\
\bottomrule
\end{longtable}

\section{Явное управление флагами PSW}
Arithmetic/status domain PSW намеренно разделён на два byte-range. \code{PSW[7:0]} --- CPU flags, \code{PSW[15:8]} --- MPU mathematical flags. Execution/control state начинается выше этого диапазона и не является writable через обычные flag instructions.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 SETF    CF       ; PSW[CF] = 1
 CLRF    AF       ; PSW[AF] = 0
 CLRCPUF          ; PSW[7:0]  = 0
 CLRMPUF          ; PSW[15:8] = 0
\end{lstlisting}

\code{SETF} и \code{CLRF} принимают те же symbolic flag names AF, CF, OF, SF, PF, ZF, RF, VF, DOMF, SNGF, OVFF, UDFF, TLSF, PLSF, INDF, INXF, которые используются branch selector namespace, но write contract намеренно заканчивается на bit 15. Попытка \code{SETF HF}, \code{CLRF TF} или \code{SETF IF} является assembler error; decoder/executor независимо отвергает такой bytecode как invalid operand. MODE многобитовое поле и отдельного selector не имеет.

Каждая single-flag instruction изменяет ровно выбранный bit и сохраняет остальные биты PSW. \code{CLRCPUF} использует маску \code{0x000000ff}, \code{CLRMPUF} --- \code{0x0000ff00}; обе операции сохраняют HF/TF/IF/MODE и reserved bits.

Практически это устраняет необходимость искусственно выполнять арифметическую операцию только ради получения заданного initial carry:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 CLRF    CF
 IADC    r64@0x00000, r64@0x00010, r64@0x00018
 IADC    r64@0x00008, r64@0x00020, r64@0x00028

 SETF    CF
 ISBB    r64@0x00030, r64@0x00040, r64@0x00048
\end{lstlisting}

\code{IADC}, \code{ISBB} и rotate-through-carry instructions продолжают использовать установленную LibMPU flag semantics; \code{SETF/CLRF} не переопределяют их арифметику, а только задают входное flag state.

\section{Ограничения разрядности}

\begin{center}
\begin{tabularx}{0.84\textwidth}{@{}L{30mm}L{62mm}Y@{}}
\toprule
\textbf{Класс} & \textbf{Простые операции} & \textbf{Трансцендентные}\\
\midrule
Integer & до 65536 bit & ---\\
Real & до 65536 bit & до 16384 bit\\
Complex & до c65536 = 2 x real32768 & до c32768 = 2 x real16384\\
\bottomrule
\end{tabularx}
\end{center}

\section{PC, CODE64 и direct/indirect control flow}
PC - 64-битный byte offset в PROGRAM. CODE64 - такой же raw PROGRAM offset внутри machine code, encoded canonical MSB-first. Прямые переходы получают target из bytecode, а indirect forms получают target через обычный 64-bit register, содержащий PROGRAM PTR64.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 обычная инструкция:     PC = old_PC + instruction_length
 JMP CODE64:             PC = target
 JSET/JCLR taken:        PC = target
 JSET/JCLR not taken:    PC = next_pc
 JMPP r64(PTR64):        PC = OFFSET(ptr), если SEG=PROGRAM
 CALL CODE64:            push next_pc; PC = target
 CALLP r64(PTR64):       push next_pc; PC = OFFSET(ptr), если SEG=PROGRAM
\end{lstlisting}

JZ/JNZ/JC/JNC/JO/JNO/JS/JNS являются assembler aliases для JSET/JCLR над конкретными PSW bit.

\subsection{Зачем нужны JMPP и CALLP}
JMP и CALL кодируют конкретный CODE64 target прямо внутри инструкции. Это удобно для statically known labels. JMPP и CALLP нужны тогда, когда target выбирается во время исполнения: function pointer, callback, таблица обработчиков, virtual dispatch, jump table или runtime-selected routine.

Code/function pointer ABI. Указатель на executable code является обычным PTR64 с SEG = PROGRAM (0x2). Offset - byte address внутри текущего PROGRAM. Отдельного архитектурного типа function-pointer не существует: это 64-битное значение в обычном r64.

\subsection{JMPP - indirect jump}
\begin{center}
\begin{tabularx}{0.86\textwidth}{@{}L{24mm}L{45mm}Y@{}}
\toprule
\textbf{Код операции} & \textbf{Source syntax} & \textbf{Машинный формат / длина}\\
\midrule
0x4003 & \code{JMPP r64@addr} & OPCODE16 + REG24 = 5 bytes\\
\bottomrule
\end{tabularx}
\end{center}

Source register содержит полный PTR64. Executor сначала читает 8 байт register view и проверяет:

ptr != NULL SEG(ptr) == PROGRAM OFFSET(ptr) < program.size

При успехе выполняется только:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 PC = OFFSET(ptr)
\end{lstlisting}

SP, FP, STACK, PSW и сам source register не изменяются. Ошибка segment selector, NULL или offset за пределами текущего PROGRAM даёт CPU\_EXEC\_POINTER\_FAULT, причём PC остаётся прежним.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; r64@0x00100 = PTR64(PROGRAM, target_offset)
 JMPP    r64@0x00100
\end{lstlisting}

Для r64@0x00100 REG24 равен 30 01 00, поэтому machine bytes инструкции:

40 03 30 01 00

Instruction boundary metadata нет. CPU проверяет только PROGRAM segment и byte range. Если runtime-created pointer указывает в середину другой инструкции, PTR64 может быть range-valid; следующая decode operation определит, образует ли последовательность bytes допустимую инструкцию. Assembler-generated code labels и

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
  .cptr label естественно указывают на начало помеченной assembler instruction.
\end{lstlisting}

\subsection{CALLP - indirect call}
\begin{center}
\begin{tabularx}{0.86\textwidth}{@{}L{24mm}L{45mm}Y@{}}
\toprule
\textbf{Код операции} & \textbf{Source syntax} & \textbf{Машинный формат / длина}\\
\midrule
0x4012 & \code{CALLP r64@addr} & OPCODE16 + REG24 = 5 bytes\\
\bottomrule
\end{tabularx}
\end{center}

CALLP использует тот же CALL ABI, что и direct CALL CODE64. Различается только источник target. После проверки PROGRAM PTR64 и наличия места в STACK вычисляется:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 next_pc = old_PC + 5
 new_sp = old_SP - 8
\end{lstlisting}

и только после всех проверок происходит архитектурное изменение:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 STACK[new_sp .. new_sp+7] = next_pc   ; raw 64-bit CODE64 offset
 SP = new_sp
 PC = OFFSET(ptr)
\end{lstlisting}

Возвратный адрес не является PTR64. CALLP, как и CALL, помещает в STACK raw 64-bit PROGRAM byte offset. Поэтому существующий RET не различает direct и indirect call: он снимает тот же CODE64 и устанавливает PC.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; r64@0x00100 = PTR64(PROGRAM, function_offset)
 CALLP   r64@0x00100
 ; execution resumes here after RET
\end{lstlisting}

Для того же r64@0x00100 machine bytes:

40 12 30 01 00

CALLP не меняет PSW и FP. Register file считается volatile across CALL по уже принятому ABI; это соглашение caller/callee, а не side effect самой инструкции.

\subsection{Atomic fault semantics CALLP}
CALLP сначала проверяет pointer, текущий PROGRAM range и возможность разместить 8-byte адрес возврата (return PC) в STACK. До успешного завершения всех проверок не изменяются PC, SP и STACK. Поэтому не существует состояния "return address уже записан, но переход не произошёл".

\begin{center}
\begin{tabularx}{0.97\textwidth}{@{}L{58mm}L{38mm}Y@{}}
\toprule
\textbf{Условие} & \textbf{Результат} & \textbf{Архитектурное состояние}\\
\midrule
Operand не является физическим 64-bit register & WIDTH/operand fault & без изменений\\
NULL или любой non-PROGRAM PTR64 & POINTER\_FAULT & без изменений\\
PROGRAM offset $\ge$ \code{program.size} & POINTER\_FAULT & без изменений\\
Недостаточно STACK для адрес возврата (return PC) & STACK\_FAULT & без изменений\\
Успех & CPU\_EXEC\_BRANCH & адрес возврата (return PC) помещён в STACK; SP/PC изменены\\
\bottomrule
\end{tabularx}
\end{center}

\subsection{Assembler directive .cptr}
Чтобы таблицы function/code pointers можно было собирать непосредственно в DATA, assembler поддерживает:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 .cptr CODE_LABEL
\end{lstlisting}

Директива занимает ровно 8 байт и после разрешения label создаёт:

PTR64(SEG=PROGRAM, OFFSET=byte\_address\_of(CODE\_LABEL))

Forward references разрешены. .cptr не вставляет automatic alignment; при необходимости таблица явно начинается с .align 8 или более сильного alignment.

Каноническое spelling - .cptr. Историческое .codeptr assembler продолжает принимать как compatibility alias, но новые исходники должны использовать .cptr. Имя .label намеренно не используется: label определяется синтаксисом name:, а эта directive создаёт 8-byte code-pointer object.

Не путать с bytecode field encoding. OPCODE16/CODE64/IMM64 внутри PROGRAM имеют canonical MSB-first encoding. .cptr находится в DATA и записывает architectural object representation PTR64, то есть те же 8 байт, которые затем LOADP r64,... помещает в 64-bit register view.

\subsection{Полный пример: indirect call + indirect jump}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 .data
 .align 8
\end{lstlisting}

dispatch:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
          .cptr indirect_function
          .cptr done

 .text
         LEA     r64@0x00000, dispatch
         LOADP   r64@0x00008, r64@0x00000
         CALLP   r64@0x00008

         PADDI   r64@0x00000, r64@0x00000, 8
         LOADP   r64@0x00010, r64@0x00000
         JMPP    r64@0x00010

         ; unreachable if JMPP works
         LDI     r64@0x00020, 99
         HALT
\end{lstlisting}

indirect\_function:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
         LDI     r64@0x00020, 42
         RET
\end{lstlisting}

done:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
         HALT
\end{lstlisting}

Первый table element вызывает функцию через CALLP. RET возвращает на инструкцию после 5-byte CALLP. Затем pointer arithmetic выбирает второй element, LOADP загружает следующий PROGRAM PTR64, а JMPP переносит PC к done. Никакой специальной SWITCH/JUMP-TABLE инструкции не требуется.

\subsection{Jump-table pattern}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; index/range validation and index*8 scaling are done by surrounding code
 ; r64@byte_off already contains the byte offset of the selected 8-byte entry
 LEA     r64@table_ptr, table
 PADD    r64@entry_ptr, r64@table_ptr, r64@byte_off
 LOADP   r64@target, r64@entry_ptr
 JMPP    r64@target
\end{lstlisting}

Это normative low-level pattern для будущего assembler/compiler. Проверка index range и перевод element index в byte offset выполняются до вычисления/использования table entry. CPU остаётся независимым от high-level конструкции switch.

\section{STACK и SP}

\term{STACK}{стек} --- отдельное архитектурное адресное пространство MCPU. Оно растёт \textbf{к меньшим адресам}: при выделении памяти значение SP уменьшается, при освобождении --- увеличивается. После создания пустого стека

\begin{center}
\code{SP = FP = stack_size}.
\end{center}

SP хранит не PTR64, а обычный 64-битный \textbf{byte offset внутри STACK}. Поэтому указатель на объект стека получается явно через \code{LEASP}/\code{LEAFP}; сам SP не содержит selector сегмента.

\begin{figure}[ht]
\centering
\begin{tikzpicture}[font=\sffamily\small,>=Stealth,x=1cm,y=1cm]
  \draw[McpuBlue,thick] (2.0,0.3) rectangle (8.3,5.7);
  \fill[McpuGrayBg] (2.02,0.32) rectangle (8.28,2.25);
  \fill[McpuGreenBg] (2.02,2.25) rectangle (8.28,5.68);
  \draw[McpuBlue,very thick] (1.65,2.25) -- (8.85,2.25);
  \node[anchor=west,color=McpuBlue] at (8.95,2.25) {SP};
  \node[color=McpuBlue] at (5.15,4.05) {свободная область STACK};
  \node[color=McpuBlue2] at (5.15,1.25) {занятые данные};
  \node[anchor=west,color=McpuBlue2] at (0.0,5.65) {малые адреса};
  \node[anchor=west,color=McpuBlue2] at (0.0,-0.12) {большие адреса; конец STACK = \code{stack_size}};
  \draw[->,McpuGreen,very thick] (9.8,3.95) -- (9.8,2.55);
  \node[anchor=west,color=McpuGreen] at (10.0,3.25) {PUSH};
  \draw[->,McpuBlue,very thick] (10.9,1.0) -- (10.9,2.0);
  \node[anchor=west,color=McpuBlue] at (11.1,1.45) {POP};
\end{tikzpicture}
\caption{Стек растёт к меньшим адресам. PUSH уменьшает SP, POP увеличивает SP.}
\end{figure}

Такое направление роста удобно для ABI вызовов: caller формирует блок аргументов (argument block), затем CALL кладёт адрес возврата (return PC) непосредственно \textbf{перед} ним, а callee может обращаться к аргументам по положительным смещениям от входного SP или от стабильного FP.

\subsection{Низкоуровневые операции STACK}

\begin{center}
\begin{tabularx}{0.96\textwidth}{@{}L{24mm}L{56mm}Y@{}}
\toprule
\textbf{Инструкция} & \textbf{Изменение SP} & \textbf{Смысл}\\
\midrule
\code{PUSH R} & \code{SP -= sizeof(R)} & Записать представление регистра в \code{STACK[SP]}.\\
\code{POP R} & \code{SP += sizeof(R)} после чтения & Прочитать значение из текущей вершины стека.\\
\code{LDSP R,off} & не изменяется & Прочитать объект по адресу \code{SP + off}.\\
\code{STSP off,R} & не изменяется & Записать объект по адресу \code{SP + off}.\\
\code{ADJSP off} & \code{SP += signed(off)} & Явно зарезервировать или освободить область стека.\\
\bottomrule
\end{tabularx}
\end{center}

CPU не добавляет скрытого padding или alignment. ABI требует 16-byte alignment перед ABI-conforming CALL, но конкретные \code{ADJSP}, padding slots и offsets формирует assembler/compiler. Низкоуровневые операции остаются byte-addressable и допускают unaligned addresses, если конкретное ABI-правило не требует большего выравнивания.

\begin{principle}
SP --- не обычная переменная. Каждое изменение SP меняет границу живой stack storage. Выделение и освобождение памяти должны быть симметричны, а любой PTR64 на освобождённую stack-область становится семантически недействительным.
\end{principle}

\section{CALL/RET, блок аргументов (argument block) и PSW calling convention}

Нормативный ABI отделяет \textbf{блок аргументов (argument block)}, принадлежащий caller-у, от 8-байтового адрес возврата (return PC), который автоматически добавляет CALL. Непосредственно перед ABI-conforming CALL значение SP кратно 16. Caller заранее резервирует цельный блок аргументов (argument block), размещает в нём hidden-result pointer (если он нужен) и explicit arguments, затем выполняет CALL.

\subsection{Размещение блок аргументов (argument block)}

Argument block строится от меньших offsets к большим в порядке параметров функции. Если функция возвращает aggregate, hidden result PTR64 занимает slot 0. Для каждого аргумента:

\begin{codebox}
\begin{verbatim}
offset = align_up(offset, alignof(argument))
argument.offset = offset
offset += sizeof(argument)

argument_block_size = align_up(offset, 16)
\end{verbatim}
\end{codebox}

Base блок аргументов (argument block) перед CALL должен быть выровнен на 16 bytes. CPU не знает типов аргументов и не вставляет padding автоматически: это правило assembler/compiler ABI.

\begin{figure}[ht]
\centering
\begin{tikzpicture}[font=\sffamily\small,>=Stealth,x=1cm,y=1cm]
  \def\xL{2.4}\def\xR{8.3}
  \fill[McpuGreenBg] (\xL,4.8) rectangle (\xR,5.6);
  \fill[McpuGrayBg]  (\xL,3.9) rectangle (\xR,4.8);
  \fill[McpuGrayBg]  (\xL,3.0) rectangle (\xR,3.9);
  \fill[yellow!10]   (\xL,2.2) rectangle (\xR,3.0);
  \draw[McpuBlue,thick] (\xL,2.2) rectangle (\xR,5.6);
  \foreach \y in {3.0,3.9,4.8} {\draw[McpuBlue2] (\xL,\y)--(\xR,\y);}
  \node at (5.35,5.2) {адрес возврата (return PC) (8 bytes)};
  \node at (5.35,4.35) {блок аргументов (argument block) +0};
  \node at (5.35,3.45) {блок аргументов (argument block) +\dots};
  \node[color=McpuBlue2] at (5.35,2.6) {tail padding до 16 bytes};
  \node[anchor=west,color=McpuBlue] at (8.65,5.2) {SP + 0};
  \node[anchor=west,color=McpuBlue] at (8.65,4.35) {SP + 8};
  \node[anchor=west,color=McpuBlue] at (8.65,3.45) {SP + 8 + \dots};
  \node[anchor=west,color=McpuBlue2] at (1.0,6.05) {состояние callee сразу после CALL};
  \draw[decorate,decoration={brace,amplitude=5pt},McpuGreen] (1.95,4.8)--(1.95,2.2)
      node[midway,left=7pt,align=right,color=McpuGreen]{argument\\block caller-а};
  \node[anchor=west,color=McpuBlue2] at (2.4,1.55) {base блок аргументов (argument block) = caller SP перед CALL; поэтому он выровнен на 16 bytes};
  \node[anchor=west,color=McpuBlue2] at (2.4,1.05) {после PUSHFP; SETFP тот же base находится по FP + 16};
\end{tikzpicture}
\caption{CALL добавляет адрес возврата (return PC) перед уже сформированным блок аргументов (argument block).}
\end{figure}

После CALL callee видит адрес возврата (return PC) по \code{SP+0}, а начало блок аргументов (argument block) --- по \code{SP+8}. RET снимает \textbf{только} адрес возврата (return PC). Весь блок аргументов (argument block) после возврата освобождает caller.

\subsection{Простые PUSH остаются допустимым сокращением}

Старый right-to-left PUSH spelling остаётся корректным там, где он создаёт тот же layout и оставляет SP кратным 16. Например два \code{r64} занимают ровно 16 bytes:

\begin{lstlisting}
PUSH      r64@arg2
PUSH      r64@arg1
CALL      f
ADJSP     16
\end{lstlisting}

Для одного \code{r64} блок аргументов (argument block) всё равно должен занимать 16 bytes:

\begin{lstlisting}
ADJSP     -16
STSP      0, r64@arg1
CALL      f
ADJSP     16
\end{lstlisting}

\subsection{CALL, RET, FP и PSW}

CALL и CALLP помещают 64-bit next PC в STACK; RET снимает его обратно в PC. Return address является raw PROGRAM byte offset (CODE64), а не PTR64. Регистра RA/LR нет.

CALL/RET не изменяют FP и не сохраняют PSW автоматически. Arithmetic/status bits считаются caller-clobbered согласно принятому ABI, а persistent control bits должны быть восстановлены callee перед обычным возвратом, если callee их изменял. Сохранение FP --- отдельная обязанность функций, которые выбрали frame-pointer convention.

\begin{principle}
CPU выполняет только механические действия CALL/RET. Типы аргументов, padding, hidden-result slot, владение блок аргументов (argument block) и сохранение долгоживущего состояния --- контракт ABI между caller, callee и compiler.
\end{principle}

\section{Return Value Area}

Верхние 8192 bytes register file зарезервированы ABI для канонического scalar return value. Это не отдельный физический регистр: результат размещается в обычном перекрывающемся register file так, чтобы \textbf{старший конец выбранного physical view совпадал с концом register file}.

\begin{center}
\begin{tabularx}{0.82\textwidth}{@{}L{34mm}L{45mm}Y@{}}
\toprule
\textbf{View} & \textbf{Physical size} & \textbf{Канонический return register}\\
\midrule
\code{r8} & 1 byte & \code{r8@0x7ffff}\\
\code{r16} & 2 bytes & \code{r16@0x7fffe}\\
\code{r32} & 4 bytes & \code{r32@0x7fffc}\\
\code{r64} & 8 bytes & \code{r64@0x7fff8}\\
\code{r4096} & 512 bytes & \code{r4096@0x7fe00}\\
\code{r65536} & 8192 bytes & \code{r65536@0x7e000}\\
\code{c64} & 8 bytes & \code{c64@0x7fff8}\\
\code{c4096} & 512 bytes & \code{c4096@0x7fe00}\\
\code{c65536} & 8192 bytes & \code{c65536@0x7e000}\\
\bottomrule
\end{tabularx}
\end{center}

\begin{figure}[ht]
\centering
\begin{tikzpicture}[font=\sffamily\small,x=1cm,y=1cm]
  \draw[McpuBlue,thick] (0.8,1.2) rectangle (11.5,2.55);
  \fill[McpuGrayBg] (0.82,1.22) rectangle (9.5,2.53);
  \fill[McpuGreenBg] (9.5,1.22) rectangle (11.48,2.53);
  \draw[McpuBlue2] (9.5,1.2)--(9.5,2.55);
  \node at (5.1,1.88) {обычная volatile register area};
  \node[align=center,color=McpuBlue] at (10.48,1.88) {Return Value\\Area, 8 KiB};
  \node[anchor=north,color=McpuBlue2] at (0.8,1.05) {0x00000};
  \node[anchor=north,color=McpuBlue2] at (9.5,1.05) {0x7e000};
  \node[anchor=north,color=McpuBlue2] at (11.5,1.05) {0x80000};
  \draw[->,McpuGreen,very thick] (1.3,3.15)--(8.95,3.15);
  \node[color=McpuGreen,above] at (5.1,3.15) {automatic register allocation растёт вверх};
\end{tikzpicture}
\caption{Верхние 8 KiB register file зарезервированы под канонический scalar result.}
\end{figure}

Return Value Area является volatile across CALL. Если caller должен сохранить результат через следующий вызов функции, он обязан скопировать его в собственный register slot или memory object.

\section{PTR64: сегментированный виртуальный}
указатель PTR64 является 64-битным архитектурным указателем, но не host pointer. Старшие 4 бита выбирают segment selector, младшие 60 - byte offset внутри сегмента.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
            SEG                                        BYTE OFFSET
       bits 63..60                                      bits 59..0
          4 bits                                          60 bits
\end{lstlisting}

Каждый selector получает виртуальный диапазон 260 bytes = 1 EiB. Назначения 0x0..0x7 зафиксированы архитектурой; 0x8..0xF остаются резервом.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 SEG         Имя             Назначение                              Guest dereference

 0x0         DATA            static/global objects                   R/W

 0x1         STACK           call/automatic storage                  R/W

 0x2         PROGRAM         machine code                            R only

 0x3         CONTROL         run control / configuration             R only

 0x4         INPUT           environment -> model                    R only

 0x5         OUTPUT          model -> environment                    R/W

 0x6         TRACE           current telemetry frame                 R/W

 0x7         HEAP            runtime dynamic storage                 R/W, low guard excluded

 0x8..0xF    reserved        future spaces                           POINTER_FAULT
\end{lstlisting}

PTR64 = (SEG << 60) | OFFSET

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 SEG(ptr)    = (ptr >> 60) & 0xF
\end{lstlisting}

OFFSET(ptr) = ptr \& 0x0FFFFFFFFFFFFFFF

NULL остаётся единственным all-zero value. 0x0000000000000000 = PTR64(DATA,0). Назначение новых selectors не меняет NULL semantics. DATA[0..15] является NULL guard; HEAP[0..15] является отдельным heap guard, но PTR64(HEAP,0) не является NULL.

ADDR64 и PTR64 - не одно и то же. ADDR64 в прямых LOAD/STORE остаётся raw DATA offset. PTR64 является runtime value с selector+offset и используется косвенными memory/ control-flow operations.

\section{Создание указателей: LEA, LEASP, LEAFP}
\subsection{LEA: полный PTR64 immediate}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 LEA r64@dst, symbol_or_expression
\end{lstlisting}

machine: OPCODE16 + REG24 + PTR64IMM = 13 bytes runtime: r64@dst = decoded PTR64 immediate

LEA сохраняет прежний размер 13 bytes, но его 64-bit machine field теперь нормативно трактуется как полный PTR64 immediate, а не как DATA-only ADDR64. Ассемблер определяет selector по section, к которой принадлежит label:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 Label section                              LEA result

 .data                                      PTR64(DATA, offset)

 .control                                   PTR64(CONTROL, offset)

 .input                                     PTR64(INPUT, offset)

 .output                                    PTR64(OUTPUT, offset)

 .trace                                     PTR64(TRACE, offset)

 .init / .text / .fini                      PTR64(PROGRAM, offset)

 .input
\end{lstlisting}

force:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
              .real 128, 0.0

 .text
\end{lstlisting}

\_life:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
              LEA   r64@0x00100, force   ; PTR64(INPUT, offset(force))
              LOADP r128@0x00200, r64@0x00100
\end{lstlisting}

Чистое absolute/.equ expression без section label сохраняет историческую DATA semantics. Для DATA-label binary encoding остаётся совместимым с прежним LEA: selector DATA равен нулю, поэтому старший nibble 64-bit field не меняет bytes.

\subsection{LEASP и LEAFP}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 LEASP r64@dst, signed_offset       -> PTR64(STACK, SP + signed_offset)
 LEAFP r64@dst, signed_offset       -> PTR64(STACK, FP + signed_offset)
\end{lstlisting}

Эти instructions остаются специальными быстрыми constructors для automatic stack objects. Формирование one-past pointer допустимо при offset, равном architectural segment size; dereference всё равно требует, чтобы полный transfer range был valid.

\section{Косвенная адресация: LOADP и STOREP}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 LOADP R/C, r64(PTR64)       ; memory[ptr] -> register
 STOREP r64(PTR64), R/C      ; register -> memory[ptr]
\end{lstlisting}

machine size = OPCODE16 + REG24 + REG24 = 8 bytes

Pointer operand всегда является physical r64. Размер transfer задаётся шириной value-register; bytes копируются без endian conversion.

\begin{center}
\begin{tabularx}{0.98\textwidth}{@{}L{25mm}L{24mm}L{24mm}Y@{}}
\toprule
\textbf{Сегмент} & \textbf{LOADP} & \textbf{STOREP} & \textbf{Причина политики доступа}\\
\midrule
DATA & да & да & обычная изменяемая память\\
STACK & да & да & автоматические объекты и кадры вызовов\\
PROGRAM & да & нет & код доступен для чтения, запись запрещена\\
CONTROL & да & нет & конфигурация принадлежит runtime/supervisor\\
INPUT & да & нет & входные воздействия принадлежат среде\\
OUTPUT & да & да & модель формирует выходные данные\\
TRACE & да & да & модель формирует текущий telemetry frame\\
HEAP & да & да & динамическая guest-память; offsets 0..15 защищены\\
0x8..0xF & POINTER\_FAULT & POINTER\_FAULT & селектор не назначен\\
\bottomrule
\end{tabularx}
\end{center}

CPU не хранит type tag у PTR64. Pointer provenance, pointee type, object lifetime, ownership и масштабирование на sizeof(T) являются ответственностью compiler/runtime ABI. CONTROL и INPUT read-only именно для guest CPU; host runtime API имеет право обновлять их в разрешённые lifecycle points.

\section{Pointer arithmetic}
Pointer arithmetic выполняется только над 60-битным BYTE OFFSET. Четырёхбитный SEG никогда не участвует в переносе или заёме и всегда сохраняется без изменения. Единица смещения - один байт.

\begin{figure}[ht]
\centering
\begin{tikzpicture}[font=\sffamily\small,x=0.22cm,y=0.85cm,>=Latex]
  \draw[fill=McpuGreenBg] (0,0) rectangle (4,1);
  \draw[fill=McpuBlueBg] (4,0) rectangle (32,1);
  \node at (2,0.5) {SEG};
  \node at (18,0.5) {BYTE OFFSET (60 bits)};
  \node[above] at (2,1) {4 bits};
  \draw[->,very thick,McpuGreen] (2,-0.25) -- (2,-1.05) node[below,align=center]{копируется\\без изменения};
  \draw[<->,very thick,McpuBlue] (8,-0.55) -- (28,-0.55) node[midway,below=2pt]{\(\pm\) signed byte delta};
  \node[below=13mm,text=McpuUrl,align=center] at (24,0) {перенос/заём за bit 59\\$\rightarrow$ POINTER\_FAULT};
\end{tikzpicture}
\caption{PADD/PSUB изменяют только OFFSET; SEG остаётся неизменным.}
\end{figure}

\subsection{Набор инструкций}
\begin{center}
\begin{tabularx}{0.96\textwidth}{@{}L{27mm}Y L{22mm}@{}}
\toprule
\textbf{Мнемоника} & \textbf{Семантика} & \textbf{Размер}\\
\midrule
PADD d,p,n & \code{d = p + signed64(n)} & 11 bytes\\
PADDI d,p,k & \code{d = p + signed OFF64(k)} & 16 bytes\\
PSUB d,p,n & \code{d = p - signed64(n)} & 11 bytes\\
PSUBI d,p,k & \code{d = p - signed OFF64(k)} & 16 bytes\\
PDIFF d,a,b & \code{d = OFFSET(a) - OFFSET(b)}, signed byte count & 11 bytes\\
\bottomrule
\end{tabularx}
\end{center}

Во всех register-формах операнды обязаны быть физическими r64. Для PADD/PSUB третий r64 трактуется как знаковое 64-битное число в дополнительном коде. Для PADDI/PSUBI смещение кодируется существующим OFF64 в canonical MSB-first byte order. Реализация использует фиксированные типы LibMPU \_\_mpu\_int64\_t и \_\_mpu\_uint64\_t, выбранные configure с гарантированной шириной 64 бита.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 PADD r64@dst, r64@ptr, r64@delta
 PADDI r64@dst, r64@ptr, 24
 PSUB r64@dst, r64@ptr, r64@delta
 PSUBI r64@dst, r64@ptr, -16
 PDIFF r64@bytes, r64@p2, r64@p1
\end{lstlisting}

\subsection{Границы и fault}
Результирующий offset обязан лежать в диапазоне 0 .. 0x0fffffffffffffff. Попытка выйти ниже нуля или выше 60-битного предела вызывает CPU\_EXEC\_POINTER\_FAULT. Destination при fault не изменяется. PSW pointer arithmetic не изменяет.

Важно: PADD/PSUB не выполняют dereference и поэтому не сравнивают offset с фактически выделенным размером DATA/STACK/PROGRAM. Они проверяют только архитектурную 60-битную границу PTR64. Фактические границы проверяются позднее, при выполнении \code{LOADP/STOREP}. Это позволяет формировать one-past и промежуточные указатели; их языковая допустимость остаётся задачей compiler.

\subsection{PDIFF}
PDIFF разрешён только если segment selectors обоих PTR64 совпадают. Разность двух 60-битных offsets всегда помещается в signed 64 bits и возвращается как число байтов. Разные SEG дают CPU\_EXEC\_POINTER\_FAULT. Само значение SEG может быть и зарезервированным: арифметика его только сравнивает/сохраняет и не пытается dereference.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; conceptual C lowering
 p + n        -> PADDI/PADD with n * sizeof(*p) bytes
 p - n        -> PSUBI/PSUB with n * sizeof(*p) bytes
 p2 - p1     -> PDIFF byte_delta; compiler scales by sizeof(*p)
\end{lstlisting}

ISA сознательно не содержит операции pointer + pointer. Типовая арифметика, масштабирование элементов, provenance и правила сравнения принадлежат high-level compiler.

\section{FP как специальное архитектурное состояние}

\term{FP}{frame pointer, указатель кадра} --- третий специальный 64-битный координатный регистр CPU рядом с PC и SP. Он не занимает байты register file и не является PTR64. В контексте CPU FP хранит raw byte offset внутри STACK.

\begin{center}
\begin{tabularx}{0.9\textwidth}{@{}L{22mm}L{36mm}Y@{}}
\toprule
\textbf{Состояние} & \textbf{Физический смысл} & \textbf{Назначение}\\
\midrule
PC & 64-bit offset в PROGRAM & адрес следующей machine instruction\\
SP & 64-bit offset в STACK & подвижная граница живой stack storage\\
FP & 64-bit offset в STACK & стабильная база текущего stack frame\\
PSW & 32-bit status/control word & FLAGS, traps/interrupt mode и status bits\\
\bottomrule
\end{tabularx}
\end{center}

\begin{figure}[ht]
\centering
\begin{tikzpicture}[font=\sffamily\small,>=Stealth,node distance=8mm]
  \node[draw=McpuBlue,rounded corners,fill=McpuGrayBg,minimum width=31mm,minimum height=10mm] (pc) {PC};
  \node[draw=McpuBlue,rounded corners,fill=McpuGrayBg,right=of pc,minimum width=31mm,minimum height=10mm] (sp) {SP};
  \node[draw=McpuBlue,rounded corners,fill=McpuGreenBg,right=of sp,minimum width=31mm,minimum height=10mm] (fp) {FP};
  \node[draw=McpuBlue,rounded corners,fill=McpuGrayBg,right=of fp,minimum width=31mm,minimum height=10mm] (psw) {PSW};
  \node[below=3mm of pc,color=McpuBlue2] {PROGRAM offset};
  \node[below=3mm of sp,color=McpuBlue2] {STACK offset};
  \node[below=3mm of fp,color=McpuBlue2] {STACK offset};
  \node[below=3mm of psw,color=McpuBlue2] {status/control};
  \node[draw=McpuBlue2,fill=McpuCode,below=15mm of $(sp)!0.5!(fp)$,minimum width=108mm,minimum height=12mm] (rf) {512 KiB перекрывающегося register file};
  \draw[McpuGreen,dashed,thick] ($(fp.south)+(0,-2mm)$) -- ($(fp.south)+(0,-8mm)$);
  \node[below=2mm of rf,color=McpuGreen,align=center] {FP не является \code{r64@...} и не занимает ни одного байта register file};
\end{tikzpicture}
\caption{FP относится к специальному состоянию CPU и не перекрывается с register file.}
\end{figure}

При создании STACK начальное состояние равно \code{SP = FP = stack_size}. FP является optional: leaf/simple function может вообще не устанавливать frame pointer. Compiler включает FP, когда нужна стабильная база для fixed locals, VLA/runtime-sized objects, spills, сложных frames или удобной диагностики.

\section{Кадр стека (stack frame): пролог и эпилог}

Сразу после обычного CALL layout определяется относительно входного SP:

\begin{center}
\begin{tabularx}{0.78\textwidth}{@{}L{34mm}Y@{}}
\toprule
\textbf{Адрес} & \textbf{Содержимое}\\
\midrule
\code{SP + 0} & адрес возврата (return PC)\\
\code{SP + 8} & начало блок аргументов (argument block)\\
\code{SP + 8 + k} & argument slot с block offset \code{k}\\
\bottomrule
\end{tabularx}
\end{center}

Функция, использующая FP, выполняет канонический prologue:

\begin{lstlisting}
PUSHFP
SETFP
ADJSP   -fixed_frame_size
\end{lstlisting}

\code{PUSHFP} сохраняет старый FP как 64-bit value и уменьшает SP на 8. \code{SETFP} фиксирует текущий SP как базу нового frame. После этого fixed locals получают стабильные отрицательные offsets от FP, а arguments --- стабильные положительные offsets.

\begin{center}
\begin{tabularx}{0.88\textwidth}{@{}L{27mm}L{34mm}Y@{}}
\toprule
\textbf{Offset от FP} & \textbf{Объект} & \textbf{Комментарий}\\
\midrule
\code{FP + 0} & сохранённый FP caller-а & значение, записанное PUSHFP\\
\code{FP + 8} & адрес возврата (return PC) & значение, записанное CALL\\
\code{FP + 16} & блок аргументов (argument block) +0 & начало блока аргументов caller-а\\
\code{FP + 16 + k} & argument slot & аргумент с block offset \code{k}\\
\code{FP - ...} & fixed locals/spills & offsets назначает compiler/frame layout\\
\bottomrule
\end{tabularx}
\end{center}

\begin{figure}[ht]
\centering
\begin{tikzpicture}[font=\sffamily\small,>=Stealth,x=1cm,y=1cm]
  \def\xL{3.0}\def\xR{8.5}
  \fill[McpuGreenBg] (\xL,5.0) rectangle (\xR,6.0);
  \fill[McpuGrayBg]  (\xL,4.0) rectangle (\xR,5.0);
  \fill[yellow!11]   (\xL,3.1) rectangle (\xR,4.0);
  \fill[yellow!11]   (\xL,2.2) rectangle (\xR,3.1);
  \fill[McpuGrayBg]  (\xL,1.2) rectangle (\xR,2.2);
  \draw[McpuBlue,thick] (\xL,1.2) rectangle (\xR,6.0);
  \foreach \y in {2.2,3.1,4.0,5.0} {\draw[McpuBlue2] (\xL,\y)--(\xR,\y);}
  \node at (5.75,5.5) {динамические объекты / VLA};
  \node at (5.75,4.5) {фиксированные локальные объекты / spills};
  \node at (5.75,3.55) {сохранённый FP caller-а};
  \node at (5.75,2.65) {адрес возврата (return PC)};
  \node at (5.75,1.7) {блок аргументов (argument block)};
  \draw[McpuGreen,very thick] (2.55,4.0)--(8.9,4.0);
  \node[anchor=east,color=McpuGreen] at (2.4,4.0) {FP};
  \draw[McpuBlue,very thick] (2.55,5.88)--(8.9,5.88);
  \node[anchor=east,color=McpuBlue] at (2.4,5.88) {SP};
  \node[anchor=west,color=McpuBlue2] at (8.8,3.55) {FP + 0};
  \node[anchor=west,color=McpuBlue2] at (8.8,2.65) {FP + 8};
  \node[anchor=west,color=McpuBlue2] at (8.8,1.7) {FP + 16 + ...};
  \node[anchor=west,color=McpuBlue2] at (0.4,6.15) {малые STACK offsets};
  \node[anchor=west,color=McpuBlue2] at (0.4,1.0) {большие STACK offsets};
  \draw[->,McpuBlue,very thick] (9.8,5.45)--(9.8,4.65);
  \node[anchor=west,color=McpuBlue] at (10.0,5.05) {SP может двигаться};
\end{tikzpicture}
\caption{Frame с FP: fixed objects имеют стабильные offsets, а SP может двигаться ниже FP.}
\end{figure}

\subsection{Инструкции управления кадром (frame instructions)}

\begin{center}
\begin{tabularx}{0.96\textwidth}{@{}L{20mm}L{25mm}Y@{}}
\toprule
\textbf{Код операции} & \textbf{Мнемоника} & \textbf{Семантика}\\
\midrule
0x5030 & \code{PUSHFP} & \code{SP -= 8; STACK[SP] = FP}\\
0x5031 & \code{SETFP} & \code{FP = SP}\\
0x5032 & \code{RESTSP} & \code{SP = FP}\\
0x5033 & \code{POPFP} & \code{FP = STACK[SP]; SP += 8}\\
\bottomrule
\end{tabularx}
\end{center}

Канонический epilogue:

\begin{lstlisting}
RESTSP           ; discard dynamic and fixed frame storage below FP
POPFP            ; restore caller FP; SP now points to адрес возврата (return PC)
RET              ; restore PC
\end{lstlisting}

CALL/RET сами FP не меняют. Сохранение и восстановление frame pointer является частью prologue/epilogue только тех функций, которые решили использовать FP. Leaf/simple functions могут работать только через SP.

\begin{principle}
Главное назначение FP --- отделить стабильную геометрию frame от временных движений SP. Fixed local всегда остаётся по тому же \code{FP-offset}, даже если функция создаёт outgoing блок аргументов (argument block)s или runtime-sized temporary storage.
\end{principle}

\section{Адресация относительно FP (FP-relative addressing)}
Три инструкции являются прямыми аналогами SP-relative операций, но используют стабильную базу FP:

\begin{center}
\begin{tabularx}{0.97\textwidth}{@{}L{20mm}L{38mm}L{42mm}Y@{}}
\toprule
\textbf{Код операции} & \textbf{Мнемоника} & \textbf{Машинный формат} & \textbf{Семантика}\\
\midrule
0x5040 & LDFP R, OFF64 & 2 + 3 + 8 = 13 bytes & \code{R = STACK[FP + off]}\\
0x5041 & STFP OFF64, R & 2 + 8 + 3 = 13 bytes & \code{STACK[FP + off] = R}\\
0x5042 & LEAFP r64, OFF64 & 2 + 3 + 8 = 13 bytes & \code{r64 = PTR64(STACK, FP + off)}\\
\bottomrule
\end{tabularx}
\end{center}

OFF64 - signed 64-bit byte displacement в canonical MSB-first encoding. Для LDFP/STFP CPU проверяет, что полный range объекта помещается в физически allocated STACK. LEAFP проверяет вычисленный offset и разрешает pointer formation на границе stack\_size (one-past), но не выполняет dereference.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; fixed local scalar at FP-8
 STFP    -8, r64@0x00100
 LDFP    r64@0x00108, -8

 ; pointer to that local object
 LEAFP   r64@0x00110, -8
 LOADP   r64@0x00118, r64@0x00110
\end{lstlisting}

\subsection{Смещения блока аргументов после установки FP}
После PUSHFP; SETFP начало блок аргументов (argument block) всегда имеет фиксированный адрес FP+16. Но offsets individual arguments вычисляются внутри блока по их ABI alignment.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 FP + 0             сохранённый FP caller-а
 FP + 8             адрес возврата (return PC)
 FP + 16            блок аргументов (argument block) base
 FP + 16 + k        argument at block offset k
 ...
\end{lstlisting}

Без aggregate return первый explicit argument имеет block offset 0. При aggregate return hidden result PTR64 занимает block offset 0, а первый explicit argument начинается с align\_up(8, alignof(arg1)). Поэтому, например, для 8-byte aligned arg1 это FP+24, а для 16-byte aligned arg1 - FP+32.

Compiler invariant: между SETFP и соответствующим POPFP FP рассматривается compiler-ом как стабильная база. PUSH/POP/CALL/ADJSP/SETSP не меняют FP.

\section{Динамическое выделение памяти в STACK и SETSP}
Dynamic objects не требуют отдельной ALLOCA-инструкции. LibMCPU использует уже существующие PTR64 + pointer arithmetic и одну операцию установки SP:

\begin{center}
\begin{tabularx}{0.92\textwidth}{@{}L{20mm}L{34mm}L{28mm}Y@{}}
\toprule
\textbf{Код операции} & \textbf{Мнемоника} & \textbf{Машинный формат} & \textbf{Семантика}\\
\midrule
0x5050 & SETSP r64(PTR64) & 2 + 3 = 5 bytes & если SEG=STACK и offset входит в allocated STACK, \code{SP = OFFSET(ptr)}\\
\bottomrule
\end{tabularx}
\end{center}

SETSP принимает только физический r64 с PTR64. DATA/PROGRAM/reserved segment дают CPU\_EXEC\_POINTER\_FAULT; STACK offset больше фактического stack\_size даёт CPU\_EXEC\_STACK\_FAULT. При fault SP не изменяется.

\subsection{Выделение N байт во время выполнения}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; r64@0x00118 contains runtime byte count N
 LEASP   r64@0x00110, 0           ; mark = PTR64(STACK, текущий SP)
 PSUB    r64@0x00120, r64@0x00110, r64@0x00118
 SETSP   r64@0x00120              ; reserve N bytes downward
 LEASP   r64@0x00130, 0           ; &object == new stack top

 ; ... use object through r64@0x00130 ...

 SETSP    r64@0x00110               ; release this dynamic scope
\end{lstlisting}

Pointer arithmetic работает в байтах. Масштабирование n * sizeof(T) и alignment выполняет compiler. CPU не добавляет hidden padding.

\subsection{Понижение VLA (VLA-style lowering)}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; VLA/dynamic object lowering.
 ; Assume compiler has already computed the required aligned byte count
 ; into r64@0x00118 at runtime.
\end{lstlisting}

f:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
         PUSHFP
         SETFP
         ADJSP   -16              ; fixed part of frame, if needed

          LEASP    r64@0x00110, 0   ; save stack mark before dynamic object
          PSUB     r64@0x00120, r64@0x00110, r64@0x00118
          SETSP    r64@0x00120
          LEASP    r64@0x00130, 0   ; PTR64 to first byte of dynamic object

          ; ... access object through r64@0x00130 ...

          RESTSP                    ; releases dynamic and fixed frame storage
          POPFP
          RET
\end{lstlisting}

Размер dynamic object. CPU получает число байтов уже вычисленным в обычном r64. Вычисление n * sizeof(T), overflow checks и align-up относятся к compiler lowering и могут использовать доступные integer operations. Механизм FP/SETSP от конкретного способа вычисления размера не зависит.

\subsection{Вложенные динамические области}

Runtime-sized objects удобно освобождать не по размеру, а восстановлением заранее сохранённой stack mark:

\begin{lstlisting}
LEASP   r64@0x00200, 0       ; внешняя отметка
; allocate object A
...
LEASP   r64@0x00208, 0       ; внутренняя отметка
; allocate object B
...
SETSP   r64@0x00208          ; release B-scope
...
SETSP   r64@0x00200          ; release A-scope
\end{lstlisting}

\begin{figure}[ht]
\centering
\begin{tikzpicture}[font=\sffamily\small,>=Stealth,x=1cm,y=1cm]
  \def\xL{3.0}\def\xR{8.8}
  \fill[McpuGreenBg] (\xL,5.1) rectangle (\xR,6.0);
  \fill[McpuGreenBg] (\xL,4.15) rectangle (\xR,5.1);
  \fill[McpuGrayBg]  (\xL,3.15) rectangle (\xR,4.15);
  \fill[yellow!11]   (\xL,2.25) rectangle (\xR,3.15);
  \fill[yellow!11]   (\xL,1.35) rectangle (\xR,2.25);
  \draw[McpuBlue,thick] (\xL,1.35) rectangle (\xR,6.0);
  \foreach \y in {2.25,3.15,4.15,5.1} {\draw[McpuBlue2] (\xL,\y)--(\xR,\y);}
  \node at (5.9,5.55) {внутренняя динамическая область B};
  \node at (5.9,4.62) {динамическая область A};
  \node at (5.9,3.65) {фиксированная часть frame};
  \node[color=McpuBlue2] at (5.9,3.37) {адресуется относительно FP};
  \node at (5.9,2.70) {saved FP};
  \node at (5.9,1.80) {адрес возврата (return PC)};
  \draw[McpuBlue,very thick] (2.55,5.85)--(9.15,5.85);
  \node[anchor=east,color=McpuBlue] at (2.4,5.85) {текущий SP};
  \draw[McpuGreen,thick] (2.7,5.1)--(9.0,5.1);
  \node[anchor=west,color=McpuGreen] at (9.2,5.1) {внутренняя отметка};
  \draw[McpuGreen,thick] (2.7,4.15)--(9.0,4.15);
  \node[anchor=west,color=McpuGreen] at (9.2,4.15) {внешняя отметка};
  \draw[McpuBlue2,very thick] (2.7,3.15)--(9.0,3.15);
  \node[anchor=west,color=McpuBlue2] at (9.2,3.15) {FP};
\end{tikzpicture}
\caption{Dynamic scopes меняют SP, но FP и fixed frame остаются стабильными.}
\end{figure}

\begin{normative}
Когда frame установлен, compiler не должен использовать SETSP для выхода выше FP и не должен захватывать caller-owned bytes. CPU аппаратно проверяет границы всего allocated STACK; принадлежность конкретных bytes текущему frame контролирует compiler/ABI.
\end{normative}

\section{C-подобная модель автоматических объектов (automatic objects)}

STACK является полноценной памятью automatic storage duration. Локальные структуры, union, массивы, VLA и runtime-sized temporaries живут в stack frame. Scalar locals могут оставаться в register file либо spill-иться в STACK.

\begin{center}
\begin{tabularx}{0.96\textwidth}{@{}L{37mm}L{58mm}Y@{}}
\toprule
\textbf{Объект} & \textbf{Рекомендуемая база} & \textbf{Время жизни}\\
\midrule
fixed scalar spill & FP + fixed negative offset & до RESTSP / возврата\\
fixed struct/array & FP + fixed negative offset & до RESTSP / возврата\\
VLA/runtime object & PTR64 от LEASP после SETSP & до восстановления соответствующей stack mark / RESTSP\\
argument & FP + positive offset; без FP --- SP-relative & в пределах call\\
\bottomrule
\end{tabularx}
\end{center}

PTR64 на automatic object имеет обычный C-like lifetime: после освобождения dynamic scope или frame он становится семантически недействительным, даже если underlying STACK bytes физически ещё существуют.

Alignment не является скрытой функцией CPU. Для ABI-conforming frame/argument layout используется максимум 16 bytes natural alignment и 16-byte CALL alignment; offsets и padding явно создаются assembler/compiler.

\section{Формальный ABI аргументов}
\begin{center}
\begin{tabularx}{0.96\textwidth}{@{}L{55mm}Y@{}}
\toprule
\textbf{Категория} & \textbf{ABI representation}\\
\midrule
Integer scalar & by value в блок аргументов (argument block)\\
Real scalar & by value в блок аргументов (argument block)\\
Complex scalar & by value в блок аргументов (argument block)\\
PTR64 & 8-byte scalar by value\\
struct/union by value & полное object representation в блок аргументов (argument block)\\
struct/union by pointer & PTR64 на исходный object\\
array parameter в C-like semantics & PTR64 на первый element\\
\bottomrule
\end{tabularx}
\end{center}

Argument block base имеет alignment 16. Каждый slot получает ABI alignment своего значения; полный размер блока округляется к 16. Padding является частью call layout, но не частью значения scalar argument.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; one r64 argument
 ADJSP   -16
 STSP    0, r64@0x00000
 CALL    f
 ADJSP   16
\end{lstlisting}

На входе callee блок аргументов (argument block) начинается по SP+8. Если callee выполняет PUSHFP; SETFP, тот же block начинается по FP+16. First explicit argument без hidden result имеет block offset 0; при hidden result его offset вычисляется по обычному align-up rule и не обязан быть фиксированным.

Почему это важно. Если hidden PTR64 занимает block offset 0, следующий argument с alignment 8 начнётся с +8, а argument с alignment 16 - с +16. Поэтому ABI не кодирует постоянную формулу «первый explicit argument всегда hidden+8».

\section{Структуры и массивы}
\subsection{Fixed local struct}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 PUSHFP
 SETFP
 ADJSP -16

 STFP    -16, r64@0x00100
 STFP    -8, r64@0x00108
 LEAFP   r64@0x00110, -16   ; &local_struct
 ...
\end{lstlisting}

\subsection{Structure by value}
Caller создаёт exact copy complete object representation в argument area. Для memory-to-memory переноса используется BMOV/BMOVI, поэтому aggregate не обязан проходить через register file и его размер не ограничен 8192 bytes максимального register view.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; struct S s occupies 48 bytes in caller frame
 LEAFP   r64@0x00100, -96      ; src = &s
 ADJSP   -48                    ; 48-byte блок аргументов (argument block), already 16-aligned
 LEASP   r64@0x00108, 0        ; dst = argument slot +0
 BMOVI   r64@0x00108, r64@0x00100, 48
 CALL    f
 ADJSP   48                     ; caller cleanup
\end{lstlisting}

\subsection{Local array / VLA}
Массив фиксированного размера получает постоянное отрицательное смещение от FP. VLA получает динамическую область STACK через LEASP/PSUB/SETSP; compiler сохраняет PTR64 на начало массива в регистре или spill-слоте, если текущий SP затем будет двигаться дальше.

\subsection{Array argument}
В обычной C-семантике array parameter передаётся как PTR64 на первый element. Копирование всего массива не происходит.

\section{Aggregate return: hidden result pointer}
Scalar integer/real/complex/pointer возвращаются через Return Value Area. Structure/union произвольного размера использует caller-provided storage и hidden PTR64.

Hidden result is argument slot 0. Caller помещает PTR64 destination в block offset 0, затем layout explicit arguments начинается после него с обычным align-up. В callee без FP block base находится по SP+8; после PUSHFP; SETFP - по FP+16.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; Example: hidden result PTR64 + aggregate argument aligned to 8
 ; block offset +0 hidden result PTR64
 ; block offset +8 explicit aggregate
 ; block is rounded up to 16-byte total size

 ; callee with FP
 PUSHFP
 SETFP
 LDFP    r64@0x00100, 16       ; hidden result = block +0
 ; explicit offsets are determined by ABI layout, not by a universal constant
 ...
 RESTSP
 POPFP
 RET
\end{lstlisting}

Callee записывает aggregate bytes через hidden PTR64. RET не копирует aggregate и не трогает Return Value Area для такого результата. Caller освобождает весь блок аргументов (argument block) одним ADJSP.

\section{Block copy: BMOV и BMOVI}
Block-copy переносит произвольное число байтов непосредственно между архитектурными memory spaces через PTR64. Register file используется только для самих указателей и, в форме BMOV, для runtime byte count. Содержимое копируемого объекта не проходит через REG24.

\begin{center}
\begin{tabularx}{0.97\textwidth}{@{}L{20mm}L{45mm}Y L{18mm}@{}}
\toprule
\textbf{Код операции} & \textbf{Мнемоника} & \textbf{Машинный формат} & \textbf{Размер}\\
\midrule
0x0150 & BMOV dst, src, count & OPCODE16 + REG24 + REG24 + REG24 & 11 bytes\\
0x0151 & BMOVI dst, src, IMM64 & OPCODE16 + REG24 + REG24 + IMM64 & 16 bytes\\
\bottomrule
\end{tabularx}
\end{center}

Все register operands этих двух инструкций обязаны быть физическими r64. Первые два r64 содержат PTR64 destination и source. Третий r64 у BMOV интерпретируется как unsigned 64-bit byte count (\_\_mpu\_uint64\_t). У BMOVI byte count находится непосредственно в PROGRAM как unsigned IMM64, MSB-first.

Семантика всегда memmove. Если source и destination ranges перекрываются в одном сегменте, результат обязан быть таким же, как у C memmove(). Направление физического копирования не является частью ISA и выбирается реализацией.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 BMOVI r64@dst_ptr, r64@src_ptr, 64
 ; copies exactly 64 bytes

 LDI    r64@size, 4096
 BMOV   r64@dst_ptr, r64@src_ptr, r64@size
 ; runtime-sized 4096-byte copy
\end{lstlisting}

\subsection{Разрешённые memory spaces}
\begin{center}
\begin{tabularx}{0.82\textwidth}{@{}L{38mm}L{35mm}Y@{}}
\toprule
\textbf{Segment} & \textbf{Source} & \textbf{Destination}\\
\midrule
DATA (0x0) & да & да\\
STACK (0x1) & да & да\\
PROGRAM (0x2) & да & нет\\
CONTROL (0x3) & да & нет\\
INPUT (0x4) & да & нет\\
OUTPUT (0x5) & да & да\\
TRACE (0x6) & да & да\\
HEAP (0x7) & да, кроме low guard & да, кроме low guard\\
0x8..0xF & POINTER_FAULT & POINTER_FAULT\\
\bottomrule
\end{tabularx}
\end{center}

BMOV/BMOVI используют те же segment access rules, что LOADP/STOREP. CONTROL и INPUT могут быть sources, но не destinations. OUTPUT/TRACE/HEAP являются обычными writable data-object spaces. PROGRAM остаётся read-only source.

\subsection{Проверка ranges и atomicity}
До первого изменения destination CPU обязан:

1. прочитать оба PTR64 и byte count; 2. проверить source segment и полный range [src, src+count); 3. проверить destination segment, write permission и полный range [dst, dst+count); 4. только после успешных проверок выполнить block move.

Правило атомарной ошибки: если диапазон source или destination недопустим, байты destination не изменяются. BMOV/BMOVI не меняют PSW, SP, FP и сами PTR64-регистры.

PTR64 offset может быть one-past физического сегмента только при нулевом размере. count == 0 является корректным no-op после проверки segment/access policy; запись в PROGRAM остаётся запрещённой даже для destination PROGRAM.

\begin{figure}[ht]
\centering
\begin{tikzpicture}[font=\sffamily\small,x=1cm,y=1cm]
  \node[anchor=west,color=McpuBlue2] at (0.2,2.7) {До \code{BMOVI dst=src+8, count=16}:};
  \foreach \i/\lab in {0/A,1/B,2/C,3/D} {
    \draw[McpuBlue] (1.0+1.5*\i,1.55) rectangle ++(1.5,0.72);
    \node at (1.75+1.5*\i,1.91) {\lab};
  }
  \draw[->,McpuGreen,thick] (1.0,1.3)--(1.0,0.92) node[below,color=McpuGreen]{source};
  \draw[->,McpuBlue,thick] (2.5,1.3)--(2.5,0.92) node[below,color=McpuBlue]{destination};
  \node[anchor=west,color=McpuBlue2] at (0.2,0.10) {После memmove-semantics:};
  \foreach \i/\lab in {0/A,1/A,2/B,3/D} {
    \draw[McpuBlue] (6.8+1.5*\i,0.0) rectangle ++(1.5,0.72);
    \node at (7.55+1.5*\i,0.36) {\lab};
  }
\end{tikzpicture}
\caption{BMOV/BMOVI определены как memmove, поэтому overlapping ranges обрабатываются корректно.}
\end{figure}

\subsection{Lowering: assignment структуры}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; C-like: dst = src;      sizeof(struct S) = 64
 LEAFP   r64@0x00100, -64        ; &dst
 LEAFP   r64@0x00108, -128       ; &src
 BMOVI   r64@0x00100, r64@0x00108, 64
\end{lstlisting}

CPU копирует complete object representation, включая padding bytes. Понимание полей структуры остаётся задачей compiler.

\subsection{Lowering: aggregate argument by value}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; source aggregate S lives at FP-96, sizeof(S)=48, align <=16
 LEAFP   r64@0x00100, -96
 ADJSP   -48                    ; complete 16-aligned блок аргументов (argument block)
 LEASP   r64@0x00108, 0
 BMOVI   r64@0x00108, r64@0x00100, 48
 CALL    consume_S
 ADJSP   48
\end{lstlisting}

Для нескольких arguments assembler/compiler вычисляет offsets внутри цельного блок аргументов (argument block) в declaration order, соблюдая alignment каждого slot; общий размер округляется к 16.

\subsection{Lowering: aggregate return через hidden PTR64}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; callee with FP; hidden result PTR64 at FP+16
 LDFP    r64@0x00100, 16        ; destination supplied by caller
 LEAFP   r64@0x00108, -128      ; local result object
 BMOVI   r64@0x00100, r64@0x00108, 128
 RESTSP
 POPFP
 RET
\end{lstlisting}

RET по-прежнему не знает о структуре. BMOVI просто переносит готовый object representation в caller-provided storage.

\subsection{Runtime-sized arrays и VLA}
\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; dst_ptr and src_ptr are PTR64; r64@0x00110 = runtime byte count
 BMOV    r64@0x00100, r64@0x00108, r64@0x00110
\end{lstlisting}

Compiler предварительно вычисляет element\_count * sizeof(T), выполняет требуемые overflow checks и передаёт итоговый byte count. BMOV не знает element type и не выполняет масштабирование.

\subsection{memcpy и memmove в C-like frontend}
Одна архитектурная операция достаточна для обеих high-level семантик. Вызов memmove естественно lowering-ится в BMOV/BMOVI. memcpy также может lowering-иться в ту же инструкцию: memmove-semantics являются более сильной гарантией и не меняют результат программы при неперекрывающихся ranges. Frontend всё равно может диагностировать нарушение своих собственных правил aliasing/overlap.

\section{ABI data layout и assembler alignment}
\subsection{Natural alignment}
Базовое правило LibMCPU ABI для обычного scalar/object storage:

natural\_alignment = min(sizeof(object), 16)

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ABI_MAX_ALIGN      = 16
 STACK/CALL_ALIGN   = 16
\end{lstlisting}

Это означает, например: r8 -> align 1, r32 -> align 4, r64/PTR64 -> align 8, r128 и все более крупные numeric objects -> align 16. Размер объекта при этом не меняется: real4096 занимает 512 bytes, но ABI-natural alignment равен 16, а не 512.

\subsection{Assembler не вставляет hidden alignment}
.integer, .real и .complex записывают bytes непосредственно в текущую DATA position. Только явный .align N меняет position. Благодаря этому один и тот же assembler поддерживает normal и packed layout.

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
 ; normal ABI-like layout
 .data
 .align 16
\end{lstlisting}

obj:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
         .integer 8, 1           ; offset +0
         .align 4
         .integer 32, 2          ; next 4-byte aligned field
         .align 2
         .integer 16, 3
         .align 4                ; trailing struct padding

 ; packed binary layout: no implicit padding
\end{lstlisting}

packed\_obj:

\begin{lstlisting}[language={},basicstyle=\ttfamily\scriptsize]
         .integer 8, 1
         .integer 32, 2
         .integer 16, 3
\end{lstlisting}

Explicit .align может быть больше 16 (например 64, 512 или 4096) для специальных таблиц, cache/page oriented data или внешнего формата. Такое требование относится к guest offset и не увеличивает ABI natural alignment типа.

\subsection{Normal и packed aggregate layout}
Для normal aggregate поля размещаются с их natural alignment, alignment aggregate равен максимуму alignment полей (не более 16), а sizeof округляется вверх до aggregate alignment. Packed aggregate имеет alignment 1, не имеет automatic internal/trailing padding и сохраняет внутренний layout вложенного normal aggregate как самостоятельного типа.

Bit-fields. LibMCPU ABI не требует отдельного bit-field layout: необходимые операции представляются обычными integer masks/shifts. Это сохраняет binary layout явным и переносимым.