«Яндекс» сообщил о «затронувшем инфраструктуру» инциденте в дата-центре в Сасово

Есть опасность того что если вручную невозможно считать с лазерной указкой лазердиск 650МБ - то данные на нём также не Ваши а производителей считывателей. Здесь важен не носитель а постоянная регенерация данных с переносом с одного на другой плюс резервирование. Это фактически постоянный процесс, в крупном датацентре условно каждый час вылетают диски и в конце смены обходчик едет с корзиной и делает хотсвоп. Начиная с некоторого объёма данных и/или их важности домашние/офисные решения перестают работать.

«Яндекс» сообщил о «затронувшем инфраструктуру» инциденте в дата-центре в Сасово

Дата-центр в бочке на дне океана чтобы охлаждался получше или спутниковый с солнечным ИБП 24/7. Потенциально - на гелии-3 из лунного реголита. В большинстве случаев вопрос скорее стоит о приватности корпоративных данных нежели о самой площадке, включая право собственности на сервер/raid, например, когда 4U выкупаются а сама стойка в дата центре арендуется (опечатана, опломбирована с воткнутыми ключами-флешками с доступом как в банковскую ячейку). Мелкие частные дата-центры на этом специализируются. Крупный хорош тем что физически всё рядом и "скорость света преодолевается быстрее от стойки к стойке чем от города к городу". Для занятий с собственными моделями и обучением ИИ это критически важно чтобы всё было компактно.

«Яндекс» сообщил о «затронувшем инфраструктуру» инциденте в дата-центре в Сасово

Ну тут как бы одно дело локальная техника в пыли с самостоятельным обслуживанием другое дело специально приспособленный для этого дата-центр с резервированием, охлаждением, пожаркой итд. Тем более для передовых и специфичных девайсов вроде этого должна быть специальная инфраструктура, на основе которой делается профессиональная работа качественно иного уровня а не мелкие заплатки.

Как мы создаём ИИ-агента для технических писателей (и почему это непросто)

По теме - используется baai/m3 эмбеддер из cloud.ru + FastMCP + qdrant

Также сделан чанкователь с использованием того же FastMCP на базе Python + tkinter
Настройки простейшие

```json
{
  "mcpServers": {
    "datasheet-vector-engine": {
      "disabled": false,
      "timeout": 60,
      "alwaysAllow": ["query_datasheets"],
      "disabledTools": [],
      "type": "stdio",
      "command": "....venv/bin/python",
      "args": [
        "....mcp_servers/local_mcp/mcp_datasheet_qdrant.py"
      ],
      "cwd": "....mcp_servers/local_mcp",
      "env": {}
    }
  }
}
```

Можно начанковать даташиты и их использовать как локальный поисковик, модель в них разбирается прекрасно. Достаточно перегнать pdf-ки в текст с сохранением layout

Вопрос почти по теме - где можно найти инструкцию как оживить GigaCode CLI, откуда ему взять API ключ - как то с GitVerse или cloud или как-то вытащить из json-а который создаётся плагином к VSCode. С VSCode плагин работает отлично

В «Бюро 1440» протестировали спутниковый интернет в заполярном посёлке Нельмин‑Нос в Ненецком автономном округе

В начале нулевых было много частных интернет-проектов, в качестве пусковой установки - леска с крыши/балкона, чтобы прокинуть витую пару с крыши на крышу, а кое-где даже и коаксиал. А для первых фай-фаев - центр управления спутниковой группировкой в виде YAGI из проволоки или намоткой вокруг трубы с рефлектором, четверть километра пробивало. Так что эра AI (Alternative Internet) уже на подходе.

Релиз языка программирования Mojo 1.1

Если это какой-то совсем уж специализированный железячный диалект то будет плыть в этой нише. Ну как VHDL-Verilog-System C как по отдельности так и в связке. Там ещё подмножества мета-языков RTL, описания AST LISP-подобные и так далее. Если действительно на нём будут делать CUDA/OpenCL/OpenMP подобные штуковины с расширениями наборов команд то уже что то ближе к делу. На худой случай сверхбыстрое развёртывание моделей и нейронок/эмбеддеров и надстройки над ними (раз позиционируется как AI), ковырять трансформеры. Пока что исходя из библиотек это чистый Web. Ну а там WebASM/GL в связке с JS-подобными, который в списке первых, там пробиться - если только выпустить браузер или попросить протиснуться туда в виде фреймворка или на худой вариант плагина по умолчанию.

Релиз языка программирования Mojo 1.1

Проблема новых языков - кодовая база для того же LLM с примерами и всем остальным и это явно не RAG а претрейнинг. Второе - наличие IDE где под капотом всё что нужно для сервиса языка - библиотеки, примеры, без возни с файлами/папками/флажками/настройками и отсутствием проблем syntax error. Оболочка, где не нужно что-либо учить или запоминать с хорошим подсказчиком. Тот же Колаб с Питоном. На главном сайте было бы очень хорошо что то вроде Try Mojo Online. Да и транслятор Python/Matlab->OpenCL или CUDA сейчас не такая проблема а синтаксисом AI владеет вполне прилично и даже на уровне архитектуры, понимая cmem<->CPU<->GPU<->cores<->gmem и прочие синхро-асихронные сущности. Вручную возиться с этим опять в стиле нулевых... ну так себе даже если вместо 5 строк будет одна. Особенно когда эту тему знает даже Алиса.

Rewrite It in Rust: когда переписывание действительно оправдано

обычно на Линуксе это делается монтированием в память для каждого запуска, тогда утилиты будут в +- одинаковых условиях, помимо всего прочего нужно отключать другие процессы и тяжёлый сетевой обмен. Вообще говоря сравнивать быстроту i/o, всё равно что на printf, это ещё то... помнится мерились как там шустро на экран пишет в консоль на 386-м и 486. Благо тогда и частота росла вместе с поколением. Что касается утилит - плюс ещё обработки различных исключений, может быть такое что вырваны там переполнение, ошибки потока, всякие проверки итд. Программа может быть быстрой но сваливаться при первом чихе, решение безопасной памяти это полумеры на многопоточке особенно. Раст ещё не стандартизирован и там фактически один поставщик для компилятора, что для энтерпрайза даёт вопрос "а потом кому звонить если что". Питон конечно тоже этим страдает но он уже фактически стал а-ля Паскаль в 90е, в каждой школе как Бэйсик + феноменальная кодовая база всего и обо всём. В вычислениях потеснил Matlab. Не говоря уже про знаменитсость С и плюсов. Всё остальное это бег вокруг скобок и предпочтений. По факту уже привели всё к LLVM а что там сверху уже не особо интересно в эпоху LLM. Да и наверняка сам модуль memory-safe для компилятора исчезающе мал по сравнению с остальным, по современным меркам - плагин для плюсов, кстати они поддерживаются gcc, даже где то проект видел.

Я перестал пользоваться самыми умными ИИ‑моделями. Программировать стало быстрее и дешевле

А внутри легендарного Лиспа тот самый AST который суть связка между тумблерами, машинным кодом, ассемблером и языком. Он даже в микро-форме присутствует в прошивке Спектрума. Чтобы не перегружать контекст, желательно использовать гарантированный тул который читает по 100 строк что-то вроде grep с заглушкой по длине, даже специально делаю shell-обёртку чтобы он не промахнулся с этим числом. Мало того, можно даже сделать Питошу который поможет модели посёрфить по ассемблерному коду (вот это уже было бы супер - ждём агентов, которые поддерживают генерацию специализированных тулов налету с прокруткой нагенерённого в отдельном окне вместо one-liner-code мучающий терминал). Скачал тут прошивку для ZX-48k просто для интереса во что там БЭЙСИК превращается

БЭЙСИК превращается, Бэйсик превращается.. в элегантный

# ZX Spectrum 48K ROM — BASIC Interpreter (Часть 1/3)

## 1. Обзор архитектуры

ZX Spectrum BASIC — ROM-интерпретатор Z80 с токенизированным вводом, двумя режимами выполнения (syntax-check / runtime), стековым FP-калькулятором (FORTH-like) и переменной памятью.

**Ключевые концепции:**
- Ввод токенизируется: команды → байты `$80`–`$FF` (1 байт вместо слова)
- Два режима: syntax-check (бит 7 `FLAGS`) и runtime
- Переменные хранятся в области `$5C00`–`5CFF` (64 байта системных переменных)
- Калькулятор — стековый, 5-байт FP числа
- Программа: `[line_num:2][len:2][tokens][end_marker=$80]`

---

## 2. Системные переменные (Memory Map `$5C00`–`$5CFF`)

Доступ через регистр `IY`. Всего 64 байта.

| Смещение | Имя       | Размер | Описание |
|----------|-----------|--------|----------|
| `$00`    | `ERR_NR`  | 1      | Номер ошибки (`$FF` = OK, 0–255 = коды ошибок) |
| `$01`    | `FLAGS`   | 1      | Битовые флаги: бит 0 — ведущий пробел (print), бит 5 — новая клавиша, бит 6 — тип результата (0=string, 1=numeric), бит 7 — режим синтаксической проверки |
| `$02`    | `FLAGS2`  | 1      | Расширенные флаги: бит 0 — TV (нижний экран), бит 1–3 — режимы |
| `$07`    | `MODE`    | 1      | Режим клавиатуры: 0=KLC, 1=E, 2=graphics |
| `$08`    | `LASTK`   | 1      | Код последней нажатой клавиши |
| `$0B`    | `DEFADD`  | 5      | Указатель определения пользовательской функции |
| `$10`    | `KSTATE`  | 16     | Состояние клавиш: `[raw][counter][delay][decoded]` × 4 |
| `$36`    | `OSPPC`   | 1      | Старый указатель оператора (для CONTINUE) |
| `$38`    | `STRLEN`  | 1      | Имя переменной из 1 символа (FOR/NEXT) |
| `$3B`    | `CHARS`   | 2      | Адрес таблицы битовых шрифтов (`$5C36`) |
| `$3D`    | `ERR_SP`  | 2      | Указатель стека ошибок (база GOSUB) |
| `$42`    | `NEWPPC`  | 2      | Номер новой строки программы (target) |
| `$45`    | `PPC`     | 2      | Текущий указатель программы (line number) |
| `$4B`    | `VARS`    | 2      | Начало области переменных |
| `$51`    | `CURCHL`  | 2      | Текущий адрес канала (указатель I2C-потока) |
| `$53`    | `PROG`    | 2      | Начало области BASIC-программы |
| `$55`    | `NXTLIN`  | 2      | Указатель следующей строки (поиск программы) |
| `$57`    | `DATADD`  | 2      | Указатель оператора DATA |
| `$59`    | `E_LINE`  | 2      | Конец текущей строки |
| `$5D`    | `CH_ADD`  | 2      | Текущий адрес символа (указатель парсера) |
| `$5F`    | `X_PTR`   | 2      | Указатель ошибки (маркер позиции) |
| `$61`    | `WORKSP`  | 2      | Начало рабочей области (стек калькулятора) |
| `$63`    | `STKBOT`  | 2      | Нижняя граница стека калькулятора |
| `$65`    | `STKEND`  | 2      | Верхняя граница стека (свободная память) |
| `$68`    | `MEM`     | 2      | Указатель памяти (область переменных/данных) |
| `$74`    | `T_ADDR`  | 2      | Временный адрес (указатель таблицы синтаксиса) |
| `$76`    | `SEED`    | 2      | Сид для `RND` |

---

## 3. Токенизация

### 3.1. Формат токенизированного BASIC

| Элемент         | Кодировка                          |
|-----------------|------------------------------------|
| Команды (NEW, RUN, IF…) | байт `$80`–`$FF` (1 байт) |
| Функции (RND, SIN, LEN…) | байт `$80`–`$FF` (1 байт) |
| Операторы сравнения (`<=`, `>=`, `<>`) | байт `$80`–`$FF` |
| Обычные символы | ASCII-код                         |

### 3.2. Таблица токенов (адрес `$0095`)

Структура: чередование `DEFB` (байт-разделитель с `$80`) и `DEFM` (строка без разделителя). Последний байт токена инвертирован (`$80 | char`) для обозначения конца.

**Функции:**

| Токен | Байт   | Расшифровка |
|-------|--------|-------------|
| RND   | `$80+'D'` | `"RND"`    |
| INKEY$| `$80+'$'` | `"INKEY$"` |
| PI    | `$80+'P'` | `"PI"`     |
| FN    | `$80+'F'` | `"FN"`     |
| POINT | `$80+'T'` | `"POINT"`  |
| SCREEN$| `$80+'$'`| `"SCREEN$"`|
| ATTR  | `$80+'R'` | `"ATTR"`   |
| AT    | `$80+'A'` | `"AT"`     |
| TAB   | `$80+'B'` | `"TAB"`    |
| VAL$  | `$80+'$'` | `"VAL$"`   |
| CODE  | `$80+'E'` | `"CODE"`   |
| LEN   | `$80+'V'` | `"LEN"`    |
| SIN   | `$80+'N'` | `"SIN"`    |
| COS   | `$80+'N'` | `"COS"`    |
| ASN   | `$80+'C'` | `"ASN"`    |
| TAN   | `$80+'N'` | `"TAN"`    |
| SGN   | `$80+'B'` | `"SGN"`    |
| ABS   | `$80+'S'` | `"ABS"`    |
| SQR   | `$80+'B'` | `"SQR"`    |
| INT   | `$80+'A'` | `"INT"`    |
| PEEK  | `$80+'K'` | `"PEEK"`   |
| USR   | `$80+'I'` | `"USR"`    |
| STR$  | `$80+'$'` | `"STR$"`   |
| CHR$  | `$80+'$'` | `"CHR$"`   |
| NOT   | `$80+'T'` | `"NOT"`    |
| BIN   | `$80+'N'` | `"BIN"`    |

**Команды BASIC (`$E6`–`$FF`):**

| Токен | Команда  | Описание              | Токен | Команда  | Описание           |
|-------|----------|-----------------------|-------|----------|--------------------|
| `$E6` | NEW      | Очистить программу    | `$F0` | LLIST    | Вывести программу  |
| `$E7` | BORDER   | Цвет рамки            | `$F1` | LET      | Присваивание (`=`) |
| `$E8` | CONT     | Продолжить            | `$F2` | PAUSE    | Ожидание           |
| `$E9` | DIM      | Объявить массив       | `$F3` | NEXT     | Итерация FOR       |
| `$EA` | REM      | Комментарий           | `$F4` | POKE     | Запись в память    |
| `$EB` | FOR      | Цикл с переменной     | `$F5` | PRINT    | Вывод              |
| `$EC` | GOTO     | Переход к строке      | `$F6` | PLOT     | Точка на экране    |
| `$ED` | GOSUB    | Подпрограмма          | `$F7` | RUN      | Запустить          |
| `$EE` | INPUT    | Ввод с клавиатуры     | `$F8` | SAVE     | Сохранить на ленту |
| `$EF` | LOAD     | Загрузить с ленты     | `$F9` | RANDOMIZE| Сид RND            |
|       |          |                       | `$FA` | IF       | Условие            |
|       |          |                       | `$FB` | CLS      | Очистить экран     |
|       |          |                       | `$FC` | DRAW     | Линия/дуга         |
|       |          |                       | `$FD` | CLEAR    | Очистить переменные|
|       |          |                       | `$FE` | RETURN   | Из подпрограммы    |
|       |          |                       | `$FF` | COPY     | На принтер         |

---

## 4. Таблица синтаксиса (Syntax Table, адрес `$1A48`)

### 4.1. Формат записи

```
[ClassByte] [SeparatorByte] [ClassByte] [SeparatorByte] ... [ClassByte] [OFFSET]
```

### 4.2. Коды классов параметров

| Класс | Описание                                      |
|-------|-----------------------------------------------|
| `$00` | Без операндов (конец оператора)               |
| `$01` | Переменная требуется (для LET: `VAR = EXPR`)  |
| `$02` | Выражение (число или строка)                  |
| `$03` | Числовое выражение, необязательное (по умолч. 0) |
| `$04` | Односимвольная переменная                     |
| `$05` | Полный синтаксический контроль (PRINT, INPUT) |
| `$06` | Числовое выражение требуется                  |
| `$08` | Два числа через запятую                       |
| `$09` | Два числа + необязательный цвет               |
| `$0B` | Команда ленты (SAVE/LOAD/VERIFY/MERGE)        |

### 4.3. Классы-рутины (CLASS-TABLE, адрес `$1C01`)

| Класс | Рутин   | Адрес  | Описание                                  |
|-------|---------|--------|-------------------------------------------|
| `$00` | L1C14   | No operands                         |
| `$01` | L1C1B   | Variable assignment + `=`           |
| `$02` | L1C2E   | Expression (SCANNING)               |
| `$03` | L1C48   | Optional numeric (default 0)        |
| `$04` | L1C59   | Single char variable                |
| `$05` | L1C6A   | Full syntax check                   |
| `$06` | L1C82   | Numeric expression                  |
| `$08` | L1E85   | Two comma-separated params          |
| `$09` | L21E2   | Colour items + coords               |
| `$0B` | L0609   | Tape command dispatch               |

### 4.4. Примеры записей

| Команда | Токен | Синтаксис        | Описание                          |
|---------|-------|------------------|-----------------------------------|
| LET     | `$E1` | `[$01] [=] [$02]` | `VAR = EXPR`                     |
| GOTO    | `$EC` | `[$06] [$00]`     | `GOTO 100` — число, конец        |
| IF      | `$FA` | `[$06] [THEN] [$05]` | `IF A>5 THEN ...` — условие + оператор |
| FOR     | `$EB` | `[$04] [=] [$06] [TO] [$06] [STEP] [$05]` | `FOR I=1 TO 10 STEP 2` |
| PRINT   | `$F5` | `[$05]`           | Полный синтакс-чек (строки, выражения, TAB) |
| INPUT   | `$EE` | `[$05]`           | Полный синтакс-чек                |
| DIM     | `$E9` | `[$05]`           | Объявление массивов               |
| SAVE    | `$F8` | `[$0B]`           | Команда ленты                     |
| RUN     | `$F7` | `[$03]`           | Необязательное число (строка, по умолч. 0) |

# ZX Spectrum 48K ROM — BASIC Interpreter (Часть 2/3)

## 5. AST-подобная структура данных в памяти

### 5.1. Программа (Program Area)

**Layout (линейная память, отсортирована по номеру строки):**

```
+-------------------+
| Line Number (2B)  |  $0000–$FFFF, $8000+ = end marker
+-------------------+
| Line Length (2B)  |  Количество байт токенов
+-------------------+
| Token 1           |  $E6 = NEW, $F7 = RUN, ...
+-------------------+
| Token 2..N        |  Или ASCII для нетокенизированного текста
+-------------------+
| End Marker ($80)  |  Конец строки
+-------------------+
| ... (следующая)   |
+-------------------+
| $80 (global end)  |  Конец всей программы
+-------------------+
```

**Пример:** `10 PRINT "HELLO"`
```
Line Num: $0010  Length: $000D (13 байт)
Tokens: $F5 $22 "HELLO" $22 $0D
End: $80
```

### 5.2. Переменные (Variables Area)

**Layout (начинается с `VARS`):**

```
+-------------------+
| Name Length (1B)  |  $01–$7F (бит 7 = инвертирован для последнего символа)
+-------------------+
| Name Chars (N B)  |  1–30 символов, регистронезависимо (в нижнем регистре)
+-------------------+
| Data (5B / var)   |  5 байт FP-число ИЛИ дескриптор строки
+-------------------+
| Name Length (1B)  |  Следующая переменная
+-------------------+
| ...               |
+-------------------+
| $80               |  Конец переменных
+-------------------+
```

**Типы переменных:**

| Тип         | Байт 0           | Байты 1+                   |
|-------------|------------------|----------------------------|
| Numeric     | Знак/экспонента  | 5 байт FP-число           |
| String      | Длина (0–255)    | Данные строки             |
| Array       | `$80 + dim`      | Размеры измерений + данные |

**Numeric (5 байт):**
```
Byte 0: Sign (0=+, 1=−) + Exponent high (biased)
Byte 1: Exponent low
Byte 2–3: Mantissa (high)
Byte 4–5: Mantissa (low)
```
Нормализация: мантисса ∈ [0.5, 1.0), экспонента со смещением 128.
Ноль: все байты = `$00`.

### 5.3. Калькулятор (Calculator Stack)

**Layout (растёт вниз от `STKEND`):**

```
High Memory
+-------------------+
| STKEND            | ← системная переменная
+-------------------+
| FP Number 5B      | ← Operand 3 (самый глубокий)
+-------------------+
| FP Number 5B      | ← Operand 2
+-------------------+
| FP Number 5B      | ← Operand 1 (top)
+-------------------+
| STKBOT            | ← системная переменная
+-------------------+
Low Memory
```

---

## 6. Калькулятор (Floating-Point Stack)

### 6.1. Формат 5-байтного FP-числа

```
Byte 0: [S][EEEEEEE]  ← бит 7 = знак, биты 0–6 = экспонента high
Byte 1: [EEEEEEEE]    ← экспонента low
Byte 2: [MMMMMMMM]    ← мантисса, байт 3 (MSB)
Byte 3: [MMMMMMMM]    ← мантисса, байт 2
Byte 4: [MMMMMMMM]    ← мантисса, байт 1 (LSB)
```

Нормализация: мантисса ∈ [0.5, 1.0), bias = 128. Ноль: все `$00`.

### 6.2. FP-CALC (Restart `$0028`) — Opcode Table

FORTH-like стековая машина. Однобайтовые операнды:

| Операнд | Мнемоника    | Описание                        |
|---------|--------------|---------------------------------|
| `$01`   | EXCHANGE     | Swap top 2                       |
| `$02`   | DELETE       | Pop top                          |
| `$03`   | SUBTRACT     | `A = B - A` (pop both, push res) |
| `$04`   | MULTIPLY     | `A = B * A`                      |
| `$05`   | DIVISION     | `A = B / A`                      |
| `$07`   | FP-CALC-2    | Рекурсивный вызов                |
| `$0F`   | ADDITION     | `A = B + A`                      |
| `$10`   | NEGATE       | `A = -A`                         |
| `$27`   | INT          | FP → integer (truncate)          |
| `$31`   | DUPLICATE    | Duplicatetop                      |
| `$34`   | STK-DATA     | Push 5B literal из след. байт    |
| `$38`   | END-CALC     | Return, HL = top of stack        |
| `$A1`   | STK-ONE      | Push 1.0                         |
| `$C0`–`$C4` | ST-MEM-0..4 | Pop → MEM-N (scratch pad)      |
| `$E0`–`$E4` | GET-MEM-0..4| Push MEM-N на стек             |

### 6.3. Пример: BEEP dur, pitch

```
Stack before: [duration] [pitch]

$31 DUPLICATE     → [dur] [pitch] [pitch]
$27 INT           → [dur] [pitch] [int_pitch]
$C0 ST-MEM-0      → [dur] (int_pitch stored)
$03 SUBTRACT      → [dur] [frac_pitch]
$34 STK-DATA      → [dur] [0.05762265]
$04 MULTIPLY      → [dur] [0.0576 × frac]
$A1 STK-ONE       → [dur] [0.0576×frac] [1.0]
$0F ADDITION      → [dur] [1 + 0.0576×frac]
$38 END-CALC      → HL = top of stack

Result: freq = base_freq × (1 + 0.0576 × fractional_pitch)
```
# ZX Spectrum 48K ROM — BASIC Interpreter (Часть 3/3)

## 7. Оценка выражений (Expression Scanning)

### 7.1. SCANNING (адрес `$24FB`) — Главный парсер выражений

Парсит выражение от `CH_ADD` до `)` или конца оператора. Алгоритм: **shunting-yard variant**.

**Алгоритм:**
1. Инициализация: `FLAGS` бит 7 = 1 (syntax-check) или 0 (runtime)
2. `E-LINE-NO` — извлечь необязательный номер строки (для RUN)
3. Цикл по токенам выражения:
   - `GET-CHAR` → пропуск пробелов, следующий значимый символ
   - Цифра/буква → разбор числа или переменной
   - `(` → рекурсивный вызов SCANNING для подвыражения
   - Токен функции → push на стек операторов
   - Оператор (+, -, *, /, ^…) → обработка приоритета
   - `,` → конец выражения (для многопараметрических команд)

**Приоритет операторов:**

| Приоритет | Оператор | FP-CALC Opcode |
|-----------|----------|----------------|
| `$0A`     | `^`      | `$C6` (to-power) |
| `$08`     | `*`      | `$C4` (multiply) |
| `$08`     | `/`      | `$C5` (division) |
| `$06`     | `+`      | `$CF` (addition) |
| `$06`     | `-`      | `$C3` (subtract) |
| `$05`     | `<=, >=, <>, >, <, =` | `$C9`–`$CE` |
| `$03`     | `AND`    | `$C8` |
| `$02`     | `OR`     | `$C7` |

**Правило:** новый оператор с более низким приоритетом → pop и вычислить стек операторов.

### 7.2. Разбор чисел и переменных

**Числа:** `[digits].[digits]E[±digits]` — пример: `123.45E-2 = 1.2345`
1. Пропуск пробелов
2. Чтение цифр в мантиссу (нормализация к 0.5–1.0)
3. Точка → коррекция экспоненты
4. `E` → умножить экспоненту на 10
5. Знак `−` → инвертировать
6. Push 5B FP на стек калькулятора

**LOOK-VARS (адрес `$28B2`) — поиск переменной:**
1. Первый символ из `CH_ADD`
2. Чтение имени (1–30 символов)
3. Поиск в области переменных (от `VARS` до `$80`)
4. Сравнение регистронезависимо

| Carry | C     | Результат          |
|-------|-------|--------------------|
| 1     | `$00` | Простая numeric    |
| 1     | `$40` | Простая string     |
| 1     | `$80` | Array              |
| 0     | —     | Не найдена (создать новую) |

### 7.3. Функции (Functions)

Диспатч при `token - $A5` в таблице `$1A48`:

| Токен | Функция | Описание | Токен | Функция | Описание |
|-------|---------|----------|-------|---------|----------|
| `$A5` | RND     | Случайное (LCG) | `$B4` | TAN     | Тангенс |
| `$A6` | INKEY$  | Клавиатура (non-blocking) | `$B5` | ASN     | Arc sine |
| `$A7` | PI      | 3.14159265… | `$B6` | ACS     | Arc cosine |
| `$A8` | FN      | Пользоват. функция | `$B7` | ATN     | Arc tangent |
| `$A9` | POINT   | Цвет пикселя | `$B8` | LN      | Натуральный лог |
| `$AA` | SCREEN$ | Дамп памяти экрана | `$B9` | EXP     | e^x |
| `$AB` | ATTR    | Атрибут символа | `$BA` | INT     | Целая часть |
| `$AC` | AT      | Позиция курсора | `$BB` | SQR     | Корень (Newton) |
| `$AD` | TAB     | Позиция TAB | `$BC` | SGN     | Знак (−1,0,+1) |
| `$AE` | VAL$    | Строка → значение | `$BD` | ABS     | Модуль |
| `$AF` | CODE    | Код символа | `$BE` | PEEK    | Байт памяти |
| `$B0` | VAL     | Строка → число | `$BF` | IN      | Порт ввода |
| `$B1` | LEN     | Длина строки | `$C0` | USR     | Машинная функция |
| `$B2` | SIN     | Синус (CORDIC) | `$C1` | STR$    | FP → строка |
| `$B3` | COS     | Косинус | `$C2` | CHR$    | Код → символ |

---

## 8. Обработка команд (Statement Handlers)

### 8.1. MAIN DISPATCH — STMT-LOOP (адрес `$1B28`)

**Алгоритм:**
1. `NEXT-CHAR` → advance `CH_ADD`
2. `GET-CHAR` → текущий символ
3. `CR` (`$0D`) → `LINE-END`; `:` (`$3A`) → `STMT-LOOP`
4. Push `STMT-RET` (обработчик ошибок)
5. Символ → `C`, `NEXT-CHAR` → past command name
6. Вычесть `$CE` (DEF FN offset) → < 0 → `REPORT-C` (Nonsense)
7. Индекс в таблицу `L1A48` → смещение к syntax entry
8. `HL = syntax entry` → `GET-PARAM`:
   - Load param byte из `[HL]`, inc HL → `T_ADDR`
   - Push `SCAN-LOOP` return, param → `C`
   - Param > `' '` → `SEPARATOR`; иначе → `CLASS-TABLE` dispatch
   - Indirect jump к class routine → pop → back to `SCAN-LOOP`

### 8.2. LET (Присваивание, `$E1`)

**Синтаксис:** `VAR = EXPR`
1. Class `$01`: fetch variable name
2. Разделитель `=`
3. Class `$02`: scan expression → результат на стеке (`HL`)
4. `LET` рутинa (`$2AFF`):
   - Проверить совпадение типов
   - String: копировать данные; Numeric: копировать 5B FP
   - Type coercion (int → FP)

### 8.3. IF (Условие, `$FA`)

**Синтаксис:** `IF condition THEN statement [ELSE statement]`
1. Class `$06`: evaluate condition
2. Разделитель `THEN`
3. Class `$05`: full syntax check following statement
4. Runtime: pop condition → 0 (false): искать `ELSE` или конец строки; ≠ 0 (true): выполнить → skip к `ELSE`/конец

### 8.4. FOR (Цикл, `$EB`)

**Синтаксис:** `FOR var = start TO end [STEP step]`
1. Class `$04`: single-char variable
2. Разделитель `=`, Class `$06`: start expr
3. Разделитель `TO`, Class `$06`: end expr
4. Class `$05`: optional STEP (default 1)
5. Runtime:
   - Store initial value
   - Allocate 13B: current(5B) + limit(5B) + step(5B) + line(2B) + stmt(1B)
   - Set bit 7 of variable name (FOR marker)
   - Call `NEXT-LOOP` test → continue/skip to matching NEXT

### 8.5. NEXT (Итерация, `$F3`)

**Синтаксис:** `NEXT [var]`
1. Class `$04`: optional variable, Class `$00`: end
2. Runtime:
   - Check `FLAGX`, lookup variable
   - Not found / not FOR → `REPORT-1`
   - Check bit 7 (FOR marker) → not set → `REPORT-I` (NEXT без FOR)
   - Increment: `GET-MEM-0` + `GET-MEM-2` → `ADDITION` → `ST-MEM-0`
   - `NEXT-LOOP` test: within range → continue; beyond → clear marker, free 13B, set `NEWPPC/NSPPC`

### 8.6. PRINT (Вывод, `$F5`)

**Синтаксис:** `PRINT [items;items;items...]`
Элементы: строки `"text"`, выражения `A,B+C`, `TAB(n)`, `AT row,col`, `;` (без newline), `,` (tab stop 10 cols)
1. Class `$05`: full syntax check
2. Runtime: loop → `SCANNING` → `STK-FETCH` → `PO-ABLE` → `PO-STORE`
3. `;` skip newline, `,` next tab stop, `TAB(n)` abs column, `AT r,c` abs position, CR newline

### 8.7. INPUT (Ввод, `$EE`)

**Синтаксис:** `INPUT ["prompt";] var1 [,var2...]`
1. Class `$05`: full syntax check
2. Runtime: string literal → prompt; set `FLAGX` bit 7; call `EDITOR`
3. `CH_ADD` → input buffer; for each var: `GET-CHAR`, `VAL-FET-2` → parse/store

### 8.8. GOTO (Переход, `$EC`)

**Синтаксис:** `GOTO line_num`
1. Class `$06`: numeric expression → target line number
2. Runtime: set `NEWPPC` to target, `NSPPC` = 0, jump to line

### 8.9. GOSUB / RETURN (Подпрограммы, `$ED` / `$FE`)

**GOSUB:**
1. Class `$06`: target line number
2. Push `NEWPPC/NSPPC` на стек ошибок (`ERR_SP`)
3. Set `NEWPPC` to target

**RETURN:**
1. Pop `NEWPPC/NSPPC` из стека (`ERR_SP`)
2. Resume execution at saved position

### 8.10. RUN / NEW / CLEAR (Управление, `$F7` / `$E6` / `$FD`)

| Команда | Токен | Действие |
|---------|-------|----------|
| RUN     | `$F7` | Start program from `PROG`, reset runtime vars |
| NEW     | `$E6` | Clear entire program area (`$80` end marker) |
| CLEAR   | `$FD` | Clear variables/screen, reset `VARS`, `MEM` |
| CONT    | `$E8` | Continue from `OSPPC` (saved line) |
| LOAD    | `$EF` | Load from tape → program area |
| SAVE    | `$F8` | Save program area to tape |
| LLIST   | `$F0` | List program to screen/printer |
| CLS     | `$FB` | Clear screen (black) |
| BORDER  | `$E7` | Set border colour |
| PAUSE   | `$F2` | Wait for interrupt (frame sync) |
| RANDOMIZE | `$F9` | Set `SEED` for RND |
| POKE    | `$F4` | Write byte: `POKE addr, value` |
| PLOT    | `$F6` | Draw point: `PLOT x,y` |
| DRAW    | `$FC` | Draw line/arc: `DRAW dx,dy` |
| COPY    | `$FF` | Copy screen to printer |
| DIM     | `$E9` | Declare array: `DIM A(10,20)` |
| REM     | `$EA` | Comment (skip to end of line) |
| PAUSE   | `$F2` | Wait for interrupt |

Вот собственно и есть тот самый AST-мотор под катом, тот же самый ассемблер. Достаточно просто визуализировать его токены на экране, это собственно то что назовём Бэйсиком, а там можно и представить хоть как Go хоть как Python или что ещё, даже индексы менять не нужно, добавить новые для классов, лямбд функций итд. В будущем как раз LLM-ка наверняка научится работать с этим напрямую без потери контекста за счёт hold-тегов.

Я перестал пользоваться самыми умными ИИ‑моделями. Программировать стало быстрее и дешевле

В точку. Нужен самостоятельный AST-инструмент. Настоящий пример который использую прямо сейчас. Лучше потратить пару дней для генерации того что необходимо, тем более модель с этим отлично справляется. Для Питона там куча нативных AST, для C - Clang
Саммари:

AST Python

# PyScanPyAST — Сканер зависимостей Python

## Обзор

Модульный инструмент для статического анализа зависимостей Python-проектов. Сканирует все `.py` файлы, строит направленный граф связей импортов и вызовов, генерирует отчёты о цепочках зависимостей и двусторонней достижимости.

---

## Архитектура

```
scanner.py (CLI точка входа)
    └── ini_reader.py (конфигурация)
    └── graph_builder.py (сборщик графа)
        ├── file_scanner.py (поиск файлов)
        └── ast_parser.py (парсинг AST)
    └── chain_report.py (отчёт цепочек)
    └── targeted_deps.py (целевой анализ)
    └── runner.py (режимы выполнения)
        ├── association_engine.py (двусторонний поиск)
        └── reporter.py (полный отчёт)
```

---

## Модули

### ini_reader.py — Менеджер конфигурации
- Читает `config.ini` из корня проекта (без дефолтов)
- Парсит `requirements.txt` для извлечения имён venv-пакетов
- Классифицирует узлы графа: Project / System / Venv через O(1) lookup по frozenset

### file_scanner.py — Поиск файлов
- Рекурсивный обход проекта, исключение директорий и расширений по конфигу
- Преобразование путей файлов в точечные имена модулей
- Фильтрация: `.venv`, `__pycache__`, `.pyc`, скрытые файлы

### ast_parser.py — Парсинг AST
- Извлечение рёбер зависимостей через `astroid`: импорты, определения функций, вызовы
- Нормализация импортов: `from X import Y` → `X.Y` каноническое имя
- Разрешение вызовов: вывод astroid → статический фолбэк с трассировкой вложенных атрибутов
- Внешние вызовы сворачиваются к корневому модулю

### graph_builder.py — Сборщик графа
- Построение `networkx.DiGraph` из распаршенных рёбер
- Разделение узлов: пространства имён модулей vs функции/методы (через анализ рёбер `contains`)
- Назначение scope каждому узлу: Project / System / Venv
- Анализ степеней: топ импортируемых модулей, топ вызывающих функций

### association_engine.py — Двусторонний поиск достижимости
- Downstream: BFS вперёд от начального модуля — все зависимые модули и функции
- Upstream: BFS назад от начального модуля — все вызывающие модули и тесты
- Построение кратчайших путей (chain) от корня к каждому достижимому узлу
- Классификация всех достижимых узлов по scope

### chain_report.py — Генератор отчёта цепочек
- BFS-трассировка полной цепочки импортов от целевого файла до листьев
- Группировка импортов по пакету верхнего уровня (напр., `ASTPythonIO/editable_ast`)
- Форматирование: дерево root → leaves + список прямых импортов для каждого файла

### targeted_deps.py — Целевой анализ зависимостей
- Фаза 1: парсинг целевого файла → внешние импорты (stdlib + third-party) + внешние вызовы
- Фаза 2: сканирование всех файлов проекта → поиск вызывающих (кто импортирует цель)
- Вывод: список внешних импортов, внешних вызовов, список модулей-вызывающих

### reporter.py — Генератор полного отчёта
- Сводная статистика: узлы, рёбра, модули, count по типам
- Топ импортируемых модулей (по in-degree) и топ вызывающих функций (по out-degree)
- Деревья зависимостей модулей + деревья вызовов функций
- Полный список всех рёбер (импорт / contains / call)
- Сворачивание внешних узлов: `typing.Any` → `typing`, `tkinter.ttk` сохраняется

### runner.py — Режимы выполнения
- Режим ассоциации: двусторонний поиск от `--init`, upstream/downstream с цепочками
- Режим полного отчёта: полная статистика проекта, деревья, все рёбра
- Форматирование текста с группировкой по scope и rollup внешних узлов

### scanner.py — Точка входа CLI
- Полный скан: `python scanner.py <проект>` → полный отчёт
- Целевой: `python scanner.py <проект> --init <модуль>` → двусторонний отчёт

---

## Внешние пакеты

| Пакет | Назначение |
|-------|-----------|
| `astroid` | Парсинг AST, вывод типов, разрешение импортов |
| `networkx` | Построение и анализ направленного графа зависимостей |

---

## Использование CLI

```bash
# Полный отчёт по проекту
python scanner.py /путь/к/проекту

# Целевой: двусторонний поиск
python scanner.py /путь/к/проекту --init alice_agent_ast.examples.foo

# Цепочка: root → leaves
python chain_report.py /путь/к/проекту alice_agent_ast.examples.foo

# Целевые зависимости: внешние импорты + вызывающие
python targeted_deps.py /путь/к/проекту alice_agent_ast.examples.foo
```

---

## Файлы вывода

| Файл | Содержание |
|------|-----------|
| `dependency_report.txt` | Полный проект: сводка, топ модули, деревья зависимостей, все рёбра |
| `association_report.txt` | Двусторонний: upstream вызывающие, downstream помощники, цепочки |
| `result.txt` | Цепочка: полное дерево цепочки + прямые импорты для каждого файла |

---

## Конфигурация

`config.ini` (обязателен в корне проекта):
```ini
[exclusions]
dirs = .git, venv, .venv, env, __pycache__, build, dist
extensions = .pyc, .pyo

[scopes]
stdlib_prefixes = builtins, abc, importlib, typing, collections, os, sys, ...

[reporting]
top_imported_limit = 15
top_calling_limit = 15
sample_call_trees_limit = 10
```

---

## Ключевые решения

1. **Только config**: нет захардкоженных списков stdlib или правил исключения
2. **Модуль vs функция**: разделение пространств имён модулей и узлов функций через анализ рёбер `contains`
3. **Нормализация импортов**: `from X import Y` → `X.Y` канонические имена, совпадающие с рёбрами импорта
4. **Разрешение вызовов**: вывод astroid → статический фолбэк, внешние вызовы сворачиваются к корневому модулю
5. **Сворачивание внешних узлов**: `typing.Any` → `typing`, `tkinter.ttk` сохраняется как исключение
6. **O(1) классификация**: lookup по frozenset для префиксов stdlib и venv пакетов

Для скана C поиск dead-code

Сканер по С файлам

# CScanFuncsPyClang — Справочник проекта

## Обзор

Python-инструментарий для статического анализа C-проектов на базе **Clang LibIndex**. Сканирует дерево исходников, извлекает AST (абстрактное синтаксическое дерево), строит матрицу вызовов, выявляет мёртвый код, отслеживает макросы и генерирует отчёты.

---

## Архитектура конвейера

```
загрузка конфигурации → парсинг AST → анализ дерева → санитизация → флаги → экспорт
                                         ↕
                                верификатор мёртвого кода
                                         ↕
                                отдельный скрипт верификации
```

```
главный скрипт (оркестратор)
  ├── Шаг 1: Загрузка конфигурации из INI-файла
  ├── Шаг 2: Разрешение препроцессорных флагов из CMake/Make
  ├── Шаг 3: Инициализация движка Clang
  ├── Шаг 4: Обход дерева файлов проекта
  ├── Шаг 5: Параллельный парсинг файлов через пул потоков
  ├── Шаг 6: Агрегация результатов в общие словари
  ├── Шаг 7: Разрешение целевых функций по вызовам
  ├── Шаг 8: Санитизация сырых данных
  ├── Шаг 9: Верификация мёртвого кода
  ├── Шаг 10: Запись выходных файлов
  └── Шаг 11: Печать сводной статистики
```

---

## Модули

### 1. Модуль загрузки конфигурации

**Назначение:** Читает INI-файл конфигурации, разрешает системные пути к заголовочным файлам LLVM, извлекает параметры конвейера и пула потоков.

**Алгоритм:**
- Парсит секции конфигурации: параметры конвейера, компилятора, исключения
- Автопоиск директории ресурсов LLVM по списку стандартных путей
- Парсинг многострочных списков (запятые, переносы строк)
- Возвращает объединённый словарь параметров

---

### 2. Модуль разрешения препроцессорных флагов

**Назначение:** Извлекает определения препроцессора из файлов сборки и подставляет их в аргументы компилятора Clang.

**Алгоритм:**
- Парсит файл CMake для поиска директив определения определений
- Парсит файлы Make для поиска переменных флагов препроцессора
- Объединяет результаты, устраняет дубликаты с сохранением порядка

---

### 3. Модуль парсинга единиц трансляции

**Назначение:** Инициализация движка Clang и парсинг файлов в AST.

**Алгоритм:**
- Создаёт разделяемый индекс Clang для всех потоков
- Формирует аргументы компилятора динамически: базовые флаги, ресурсы, include-пути, флаги из сборки
- Для заголовочных файлов пропускает тела функций для ускорения
- Проверяет файлы на соответствие критериям обработки (расширение, исключения)
- Возвращает единицу трансляции с полным AST

---

### 4. Модуль однопроходного обхода AST

**Назначение:** Один проход по дереву AST извлекает все метаданные без повторных обходов.

**Извлекаемые сущности:**
- Объявления и определения функций с метаданными (имя, строка, тип, статичность, длина тела)
- Определения структур с очисткой анонимных имён
- Явные вызовы функций с дедупликацией по строке и имени
- Косвенные вызовы через указатели (только если целевой узел — функция)
- Определения макросов
- Точки расширения макросов

**Алгоритм:**
- Прямой обход дерева с проверкой принадлежности узла текущему файлу
- O(1) дедупликация через хеш-множества для каждого типа сущности
- Вычисление длины тела функции по диапазону строк

---

### 5. Модуль санитизации данных

**Назначение:** Фильтрация ложных срабатываний, обработка граничных паттернов C-кода.

**Алгоритмы:**
- **Дедупликация заголовков:** при многократном включении одного заголовка из разных файлов сохраняется только первый парсинг
- **Разрешение коллизий имён:** для статических функций формируется составной ключ из пути файла и имени, предотвращающий столкновения
- **Фильтрация мёртвого кода:** проверяет наличие вызовов по составному ключу с fallback на простое имя, исключает заданный список функций
- **Полный пайплайн:** последовательное применение всех трёх шагов

---

### 6. Модуль генерации отчётов

**Назначение:** Буферизованная запись трёх выходных файлов в виде единого блока данных.

**Выходные файлы:**
- Сводка функций: список всех функций по файлам, неиспользуемые, статические с локальным охватом, функции с единственным вызовом
- Сводка структур: список структур с дедупликацией
- Сводка перекрёстных ссылок: определения макросов, точки расширения, неиспользуемые макросы

**Алгоритм:**
- Формирование каждого раздела в памяти через буфер строки
- Однократная запись всего содержимого в файл

---

### 7. Модуль верификации мёртвого кода

**Назначение:** Классификация кандидатов в мёртвый код по агрегированным данным вызовов без повторного парсинга.

**Алгоритм для каждой функции:**
1. Проверка списка исключений → ложноположительный результат
2. Двухключевой поиск в словаре вызовов: составной ключ → простое имя → сырое имя
3. Наличие записей о вызовах → ложноположительный, отсутствие → действительно мёртвый

**Возврат:** Разделённый список на подтверждённо мёртвые и ложноположительные функции.

---

### 8. Отдельный скрипт верификации через чистый AST

**Назначение:** Верификация мёртвого кода исключительно через Clang AST, без regex и grep.

**Алгоритм:**
- Парсит все файлы исходного кода проекта
- Для каждого узла AST проверяет явные вызовы и ссылки на функции
- Пропускает узлы, соответствующие определению самой функции
- Проверяет принадлежность узла текущему файлу (исключает включённые заголовки)
- Строит матрицу: подтверждённо мёртвые / живые с AST-верифицированными точками вызова

---

### 9. Главный скрипт (оркестратор)

**Назначение:** Объединяет все модули в единый конвейер.

**Конвейер:**
1. Загрузка конфигурации
2. Разрешение флагов из файлов сборки
3. Инициализация движка Clang
4. Сбор списка файлов обходом дерева
5. Параллельный парсинг через пул потоков (движок Clang освобождает блокировку интерпретатора)
6. Агрегация результатов в общие словари без копирования данных
7. Разрешение целевых функций по матрице вызовов
8. Санитизация сырых данных
9. Верификация мёртвого кода
10. Запись выходных файлов
11. Печать сводной статистики

---

## Зависимости

```
clang.cindex          # Bindings Python для движка Clang LLVM
configparser          # Стандартная библиотека — парсинг INI
pathlib               # Стандартная библиотека — работа с путями
concurrent.futures    # Стандартная библиотека — пул потоков
io.StringIO           # Стандартная библиотека — буферизованная запись
```

---

## Запуск

```bash
# Полный конвейер
python checker.py /path/to/c/project

# Только верификация мёртвого кода
python verify_dead.py /path/to/c/project

# По умолчанию (без аргумента) — путь по умолчанию
python verify_dead.py
```

---

## Выходные файлы

| Файл | Путь | Содержимое |
|------|------|-----------|
| Сводка функций | В корне проекта | Функции, неиспользуемые, статические, с единственным вызовом |
| Сводка структур | В корне проекта | Структуры |
| Сводка перекрёстных ссылок | В корне проекта | Макросы, расширения, неиспользуемые макросы |

---

## Ключевые оптимизации

| Оптимизация | Где | Эффект |
|-------------|-----|--------|
| Однопроходный обход AST | Модуль анализа | В 6 раз быстрее (было 6 отдельных обходов) |
| Пул потоков | Главный скрипт | Параллельный парсинг с освобождением блокировки интерпретатора |
| Дедупликация O(1) через хеш-множества | Модуль анализа | Устранение дубликатов вызовов, ссылок, макросов |
| Дедупликация заголовков | Модуль санитизации | Предотвращение дублирования при многократном включении |
| Составные ключи для статических функций | Модуль санитизации | Корректное отслеживание символов с локальной областью |
| Буферизованная запись блоков | Модуль экспорта | Однократная запись в диск вместо тысяч мелких записей |
| Пропуск тел функций в заголовках | Модуль парсинга | Ускорение парсинга заголовочных файлов |
| Верификация мёртвого кода O(1) | Модуль верификации | Без повторного парсинга файлов |
| Автоопределение флагов препроцессора | Модуль флагов сборки | Автоматическое извлечение определений из файлов сборки |

Фактически можно сказать код больше уже и не нужен - достаточно знать его внутреннюю структуру. Это уже новый этап развития языков - по-сути от них ничего не требуется кроме скелета AST, а далее там и рефакторинг и всё что угодно, благо LLM понимает этот формат особенно для Питона, достаточно указать необходимые тулы и можно таргетированно менять всё что угодно без ошибок синтаксиса как таковых, так как операция производится уже внутри языка.

-> также дело не в том что модель может по тексту шагать (это кстати можно сделать в виде скилла - что после нахождения чанков идти по путям к этим txt), а в существенной экономии токенов при множественных запросах по смыслу. То есть в векторной БД уже сразу она может сходу найти ответ на запрос, там сразу видно что то вроде ADC калибровка, PWM тайминги, GPIO назначение входов, ADC режимы семплирования итд. При прямом поиске вероятность глюков без вектора возрастает очень сильно. Тем более эту задачу вполне можно сплавить субагентам, причём самым "туповатым" и использовать только для взаимодействия с этой базой но саммари будет более чем достаточно для принятия решений уже оркестрирующей моделью.

Я перестал пользоваться самыми умными ИИ‑моделями. Программировать стало быстрее и дешевле

А были ли внешние инструменты - тот же Qdrant+BAAI-m3 эбмеддер, сейчас в облачных сервисах полно этого добра. Делается векторная БД, затем чанкуется любой даташит что под руку попал (включая код с коммент-промпт форматом - не пренебрегайте этим!) и модель всё делает почти так как руками, хоть Алиса хоть Сбер. Мне очень всё это дело помогло сделать микро-проект с PWM/ADC/UART/I2C/SPI с DMA, все адекватные конечные автоматы с фоллбеками и обработчиками ошибок, практически на уровне main(){} с таймерами миниатюрная RTOS, полное понимание проблем RMW с гонкой данных и всё это впихнуть в 64 к флеша и 20к озушки, прочих вкусных протокольных внешних микрух а-ля SPI дисплейчик, мультиплексоры I2C и умные драйверы шаговых. Плюс ещё скиллы соответствующие и промпт-инъекции чтобы направить в нужное русло ну и конечно же md-саммари с хорошей цепочкой и контрольным выводом, плюс питонячьи тесты (уже давно отодвинул Matlab) и тестирующие C-обёртки. Практически можно не использовать stdlib а генерировать printf/scanf по месту и прочие парсеры, умещаясь в килобайты как на каком-нибудь спектруме, самое невероятное - практически отпала необходимость искать чьи-либо библиотеки (!) для периферии, шрифтов, рендеров итд, всё генерируется по месту, остаётся только что-то вроде HAL/SPL на уровне спецификаций регистров управления. Вообщем это добротный джун/миддл с опытом работы 50+ лет в отрасли, начиная от Z80 и до GPU/FPGA.

Выбираем бэкенд в 2026 (PHP, Dart и C++ Drogon)

Модели ad hoc, применимо к синтезу необходимого функционала с минимальным количеством "глюков" и расходом токенов при поиске необходимых данных - собственно это и есть специализированные модели с файн-тюном. Вообще говоря это довольно обширная задача - синхронизация документации и того как это реализовано с точки зрения дальнейшего использования хоть LLM хоть питон-генератором. Обычно делается векторная БД с соответствующими туда запросами агентами, далее по чанкам можно уже дать если необходимо исходный документ. До сих пор это делалось человеком для человека но не для машины так скажем. Все упомянутые в публикации инструменты имеют уже историю лет 20-30 и отвечают задачам на тот момент когда они только появились. Новейшие же инструменты требуют совершенно других подходов, здесь уже язык уходит на второй план, на первом месте это генерация кода под задачу, мета-языки спецификаций, обёртка тестами, автоматизация проверки граничных значений.

Выбираем бэкенд в 2026 (PHP, Dart и C++ Drogon)

Сейчас скорее проблема не бэкэнда как такового а спецификаций, которые не отражают текущие потребности. С одной стороны давлеющее легаси из 90-х с другой микросервисы, распределённые архитектуры, асинхронность и кроссплатформ. Поэтому тут язык уже не важен, главное чтобы он (вместе с фреймворком) мог обернуть необходимые протоколы без лишней рутины, ну и конечно же если есть для этого скиллы, MCP или даже файн-тюн модели то это несомненно перевесит любые недостатки языка.

Простой способ вычислить размер структуры/класса Возьмем...

на DSP иногда бывает так что char это 16 бит. И по-хорошему бы всё это оборачивать pragma pack или pragma align, причём особенно весело это на Tiny C Compiler. Атрибуты компилятора и структуры, включая размещение оного в регистрах/памяти/авто-стеке это отдельная боль переносимости. Если что то надо захардкодить без вопросов - директивы обязательны, с хорошим доком вокруг или даже md-шку со ссылками на номера строк чтобы самому вспомнить и агенту проще было.

На ТСПУ начали перехватывать открытые DNS запросы к 1.1.1.1, 8.8.8.8

Зачем картинки, когда есть вполне определённый текст - Постановление Правительства РФ от 27.10.2025 N 1667 и № 156-ФЗ. Многофункциональный сервис, наверняка API будет соответствующий. Удобно, можно забыть про всякие netstat, tracert, tcpdump, dig как пережитки прошлого

На ТСПУ начали перехватывать открытые DNS запросы к 1.1.1.1, 8.8.8.8

А в чём проблема сделать нормальный захардкоженный утверждённый атлас белых IP адресов и распространять через киоск "Союзпечать", создать Единый классификатор адресов, ГОСТ. Например резольвить aaa.bbb.ccc.ddd 001. - айпишники пожарных организаций, 002 - полиция, 003 - скорая, 004 - сайт Газпром итд

7 месяцев вайбкодинга: как в одиночку делать то, что раньше требовало команду

Отличный опыт! Однако я бы добавил:
- не следует захламлять контекстное окно скиллами и универсальными правилами для всего, писать под конкретную задачу, вычищать инъекции, оставлять только то что нужно
- писать кратко, за данными идти в локальный txt файл с просьбой читать последовательно sed/grep/cat
- обязательно использовать MCP для внешних запросов например Context7
- абсолютное добро это индексация кодовой базы данных с Qdrant например
- лучшее решение для работы с документацией - облачный или локальный MCP с индексацией тем же Qdrant-ом, некоторые документы и файлы просматривать чанкователем и подгонять под хорошие чанки
- делайте в промпт инъекции от других моделей, запускать для решения сложной задачи несколько агентов и копипастить между ними, включая даже бесплатные ИИ из поисковиков - у них есть fine tuning и прочие плюшки с актуальными данными, агентные модели могут не знать современное состояние дел особенно для редких библиотек
- использовать Питон-тесты для обёртки сложных случаев и Питон-генераторы для анализа данных, не делать пытку модели проанализировать Json в миллион строк, только скрипт который разберёт необходимый фрагмент.

Президент РФ подписал закон о регулировании искусственного интеллекта

Вот это самый интересный вопрос. Почитайте у Соурскрафт (пункт 5) или Сбера Гигакод (пункт 6) пользовательское соглашение - там передаётся компаниям безотзывная простая (не исключительная) лицензия на то что подаётся на модель и то что с неё идёт. Если почитать что в замке у шефа - там авторские права принадлежат автору, то есть промпты и вывод модели а вот лицензия тоже вроде как на контент передаётся Гуглам, Антропикам итд, есть кто в теме тут - поправьте пожалуйста на этот счёт. Навскидку пока что звучит так, что всё что не делается с облачной моделью - лицензия на любые данные передаётся держателю модели. То есть он может их использовать для претренинга, файн тюнинга, RAG и просто выложить где нибудь как что то интересное. Вообщем необходимо результат вайбкода сразу же столбить на опенсоурс, формально это передача лицензии автором. Полностью управление правом - это опечатанная серверная стойка с шифрованием или локальная видеокарточка.

Я перенёс на Python библиотеку, которой физики пользуются двадцать лет. Перевод оказался самой лёгкой частью

На самом деле проблема такая же для различного рода симуляторов схем. EPS и прочие, добавки 1/(delta+x^2) где delta нечто бесконечно малое и прочее и прочее. Тут важнее скорее всего обусловленность задачи. Если она имеет дико разнесённые постоянные времени (пространства), от очень крупной сетки до мельчайшей то здесь NaN/ +-inf скорее exception флажки нежели математика. То есть такие вещи обычно обыгрываются некими fp константами которые предотвращают насыщение и выводят осознанное исключение без математических приветов. Тут либо полу-символические методы если уж совсем дело далеко зашло а-ля правило Лопиталя (например в SPICE есть symbolic derivative) либо все места содержащие деление или умножение дополнять на проверку. В FP умножение большого на малое тоже может дать не очень хороший результат. Тем более в процессорах общего назначения нет теневых разрядов. Например в DSP при заявленной разрядности в 32 бит аккумулятор может быть все 40 (32+тень, guard bits), чтобы не потерять крайние младшие разряды при умножении на малые коэффициенты и обеспечить накопление результата. 0.5*0.5=0.25 а не 0.2, и ошибка накапливается довольно большая, на этот счёт имеется даже определение - "численный разогрев" (numerical heating) требующий double precision

8-битному процессору Zilog Z80 исполнилось 50 лет

Это было время одноразовых ПЗУ в виде картриджей для Денди. Кстати большинство проблем на Спектруме были те самые динамические ОЗУ 565й серии которые вылетали с любым чихом с завидной регулярностью. Там ещё от производителя зависело вроде несколько заводов их выпускали (корпусировали)