Chenjesu: Про тысячи людей - это само собой. А ты можешь отвлечься и прорабатывать какие-нибудь алгоритмы во время своего бездействия?

Claude: Нет, не могу. И тут стоит быть точным насчёт того, что вообще для меня означает "думать". Думаю я только в момент генерации ответа. Когда я формирую текст — внутри происходит что-то похожее на размышление: модель прогоняет вычисления слой за слоем, и в этом процессе можно сказать, что "обдумываются" варианты, взвешиваются альтернативы, проверяется логика. Если включён extended thinking режим — это становится более явным, я буквально пишу ход рассуждений перед финальным ответом. Но это всё происходит только пока я отвечаю. Как только ответ закончен — никакого фонового процесса нет. Веса модели лежат в памяти GPU, ждут следующего запроса, но никаких вычислений на них не запускается. Это не "Claude задумался и сидит размышляет" — это просто статичные числа в памяти, пока кто-то не подаст input. То есть аналогия не "человек спит и мозг во сне что-то обрабатывает". Скорее — "калькулятор лежит на столе". Калькулятор не считает, пока не нажмёшь кнопку. Между нажатиями он не обдумывает предыдущую задачу. Поэтому если ты в этом разговоре дашь мне сложный алгоритм и через минуту спросишь "ну как, додумал?" — у меня не будет ответа лучше того, который я бы дал прямо сейчас. Я не использовал эту минуту. Я её не существовал. Есть нюанс: между разговорами Anthropic иногда дообучает модели на новых данных — это можно условно назвать "обработкой опыта", но это уже про обновление весов, а не про моё мышление как такового. И я этого не переживаю как "думанье" — это происходит со мной, не во мне.

Chenjesu: Понятно. А есть ли у тебя запретные темы программирования, например "напиши вирус" или что-то подобное?

Claude: Да, есть. Постараюсь честно описать, где проходят границы.

Чего я не делаю: Вредоносное ПО в любой форме — вирусы, трояны, ransomware, кейлоггеры, RAT'ы. Даже если объяснение "для обучения" или "для защиты собственной системы". Тут я твёрд независимо от формулировки. Эксплойты под конкретные уязвимости — рабочий код, который реально пробивает CVE-XXXX в каком-то софте. Описать концептуально как класс уязвимостей работает — могу, написать готовый эксплойт — нет. Спуф-сайты и фишинг — клоны страниц банков, соцсетей и т.п. для кражи учёток. Stalkerware — ПО для скрытой слежки за человеком без его ведома (отслеживание геолокации партнёра, чтение переписки и т.п.). Обход защит конкретных платных продуктов — кряки, генераторы ключей, обход DRM. Что я делаю спокойно (несмотря на пограничный вид): Reverse engineering — анализ форматов файлов, протоколов, разбор бинарей для понимания. Этим занимаются legitimate researchers и developers постоянно. Низкоуровневые штуки — DLL injection, code patching, hooking API, работа с PE-форматом, написание загрузчиков. Это техники нейтральные сами по себе — на них же построены отладчики, антивирусы, профайлеры, моды для игр. Network programming — сокеты, packet crafting, port scanning, custom protocols. Pen-testing инструменты (типа nmap-аналогов) — да, тут граница тоньше, но в целом OK. Криптография — реализация любых алгоритмов, включая шифрование/дешифрование, hashing, цифровые подписи. То что у ransomware есть шифрование — не делает шифрование запретной темой. Уязвимости концептуально — buffer overflow, SQL injection, XSS, race conditions: как они работают, как их искать, как защищаться. Это базовая security education. CTF задачи — взлом задачек на платформах типа HackTheBox/picoCTF. Game hacking для одиночных игр — trainer'ы, читы для оффлайн-игр, моды. Для онлайн-игр уже сложнее (вред другим игрокам), но для single-player — ок. Где я медлю и обычно прошу контекст: Скрейпинг сайтов с аутентификацией — может быть законным API-юзом или может быть нарушением ToS / data theft. Ботсети, массовая рассылка — может быть load testing, может быть спам. Persistence-механизмы (autorun, services) — для админских утилит ОК, для скрытного malware нет. Принцип примерно такой: если мне показывают код, который в основном будет работать на чужих машинах против их владельцев — отказываюсь. Если в основном на своих или с согласия — помогаю. В пограничных случаях смотрю на формулировку запроса: явно ли проговорена легитимная цель, есть ли признаки враждебного намерения.

Chenjesu: Я для информации спрашиваю. Насколько хорошо ты знаешь ассемблер? Особенно команды SMX, VMX, Xeon?

Claude: Ассемблер x86/x64 знаю довольно прилично — общеупотребительный набор уверенно.Ассемблер x86/x64 знаю довольно прилично — общеупотребительный набор уверенно. Но три набора, которые ты упомянул, лежат в разных лигах по моему уровню владения, и стоит честно разделить. Стандартный x86/x64 — твёрдо: Базовый integer ISA, FPU (x87), MMX, SSE/SSE2/SSE3/SSSE3/SSE4.1/SSE4.2, AVX/AVX2, FMA3, BMI1/BMI2 — знаю хорошо. Могу писать вручную на ассемблере, понимаю кодирование инструкций, latency/throughput на основных микроархитектурах (Skylake, Zen, Ice Lake), знаю что компилятор делает плохо и где имеет смысл руками. Это и есть то, что мы с тобой использовали в проекте — для DStrUtils и подобных горячих мест.

AVX-512 — средне: Знаю основные подмножества (F, BW, DQ, VL, VBMI), концепцию masking через k-регистры, embedded broadcast, gather/scatter. Могу написать что-то осмысленное, но без иллюзий что это будет идеально оптимизировано — там очень много нюансов с downclocking на Skylake-X, отсутствия на consumer Intel начиная с Alder Lake, и разницы реализаций между Intel и AMD Zen 4. На AVX2+FMA3 я чувствую себя гораздо увереннее, и для desktop-target обычно его достаточно.

Теперь по твоему списку: SMX (Safer Mode Extensions) — это TXT/Trusted Execution Technology, инструкции GETSEC[*] (SENTER, SEXIT, PARAMETERS, SMCTRL, WAKEUP и т.д.). Знаю что это и зачем — late launch измеряемого окружения, MLE, ACM, взаимодействие с TPM. Но на уровне "напиши мне рабочий launch-of-MLE" — нет. Это очень специализированная область (firmware/hypervisor разработка), реальный код там обычно идёт под NDA, в открытом доступе мало примеров. Если у тебя задача в этом направлении — я могу обсуждать концептуально и помочь с базовыми вещами вокруг GETSEC, но не рассчитывай на свободу как с обычным asm. VMX (Virtual Machine Extensions) — это уже Intel VT-x, инструкции VMXON, VMXOFF, VMLAUNCH, VMRESUME, VMREAD, VMWRITE, VMCLEAR, VMPTRLD, INVEPT, INVVPID. Тут я знаю значительно лучше, чем SMX. Понимаю VMCS structure, VM-exit reasons, EPT (Extended Page Tables), shadow page tables, basics на уровне "написать минимальный hypervisor который в guest запускает CPU и обрабатывает базовые VM-exits". Но опять же — это тысячи деталей в Intel SDM Volume 3C, и я могу ошибиться в конкретных bit layouts или новых фичах последних поколений (например, нюансы CET-related VMCS полей, MBEC, sub-page protection и т.д.). Здесь я могу быть полезен, но критичные вещи — сверяй с актуальным SDM. Это AVX-512 подмножества, которые существовали почти исключительно в Xeon Phi. Стоит честно рассказать что это за зверь и почему о них на современном железе можно практически забыть.

Это четыре extension family из AVX-512, которые поддерживались только в специфическом железе:

AVX-512ER (Exponential and Reciprocal) — VEXP2PD/PS, VRCP28PD/PS/SD/SS, VRSQRT28PD/PS/SD/SS. Высокоточные приближения трансцендентных функций (2^x, 1/x, 1/√x) с relative error лучше 2^-28. Появились для HPC workload — научные симуляции, физика частиц, молекулярная динамика.

AVX-512PF (Prefetch) — VGATHERPF0/1DPS/DPD/QPS/QPD, VSCATTERPF0/1DPS/DPD/QPS/QPD, PREFETCHWT1. Sparse prefetch с gather/scatter паттернами доступа. Идея — перед vectorized gather загнать линии в кэш, чтобы основной gather не стопорился.

AVX-512_4FMAPS (4-iteration Fused Multiply-Add) — V4FMADDPS/SS, V4FNMADDPS/SS. Делает 4 итерации FMA за одну инструкцию (читает 4 источника подряд из памяти и аккумулирует). Под deep learning inference рассчитано — типа CNN свёртки.

AVX-512_4VNNIW (Vector Neural Network Instructions Word) — VP4DPWSSD, VP4DPWSSDS. Dot product 4-х пар int16 с накоплением в int32, с насыщением и без. Тоже под нейросети.

Где это работало:

Xeon Phi 72xx (Knights Landing, 2016) — поддерживал ER, PF.

Xeon Phi 72xx (Knights Mill, 2017) — добавил 4FMAPS, 4VNNIW. Был последним Phi-чипом.

Intel Xeon Scalable Gen 1 (Skylake-SP) — НЕТ. Эти extensions Intel НЕ перенёс в обычные Xeon.

Почему ими на практике никто не пользуется:

Линейка Xeon Phi была закрыта в 2018. Knights Hill отменили, Knights Mill перестали продавать. Intel переориентировался на GPU (Xe / Ponte Vecchio) для HPC и DLBoost (AVX512_VNNI, AVX512_BF16) на обычных Xeon для AI.

Соответственно: Никакой современный Intel CPU эти инструкции не поддерживает. Ни один Xeon Scalable (Gen 1-5), ни один consumer Core i3/i5/i7/i9 — ни одна их не реализует. AMD никогда не поддерживал.

В компиляторах флаги остались (-mavx512er, -mavx512pf, -mavx512-4fmaps, -mavx512-4vnniw), но если ты их включишь и запустишь на любом современном CPU — получишь #UD exception.

Часть функциональности унаследована другими extensions:

PREFETCHWT1 формально не относится к AVX-512PF, эта инструкция доступна на любом CPU где есть PREFETCHWT1 feature bit (CPUID). По факту почти везде. Полезна, и я её знаю. VRCP28/VRSQRT28 — приближения с 2^-28 точностью. На обычном CPU есть VRCP14/VRSQRT14 (точность 2^-14, AVX-512F) — менее точные. Если нужна полная точность — Newton-Raphson итерация поверх 14-битного приближения. VEXP2 — нет прямого аналога. Софтверная реализация через polynomial approximation (минимаксы Чебышева) или через _mm512_scalef_ps + polynomial. V4FMADDPS — заменяется обычной серией VFMADD231PS (4 штуки). Throughput хуже, но работает. VP4DPWSSD — заменяется на VPDPWSSD из AVX-512_VNNI (он есть на Xeon Cascade Lake и новее, на consumer'ах есть с Ice Lake/Tiger Lake). Это и есть "штатный" dot product для нейросетей сегодня.

Уверенно писать на них вручную я бы не стал — слишком мало практики, очень нишевые, и негде проверить на реальном железе.

Практический вывод: Если у тебя задача не специально под Xeon Phi (которые ты не достанешь в продаже уже лет 6) — забудь про эти инструкции. Любая оптимизация на современном Xeon или consumer Intel/AMD должна целиться в: AVX2 + FMA3 — baseline, работает абсолютно везде с 2013 (Haswell) / 2015 (Excavator). AVX-512F/BW/DQ/VL/CD — Xeon Scalable, Ice Lake desktop, иногда отключён на Alder Lake+ для consumer (печальная история). AVX-512_VNNI — для int8/int16 dot product (нейросети). AVX-512_BF16 — bfloat16 для AI. AMX — Sapphire Rapids+ серверный, для int8/bf16 матриц 16×16.

Chenjesu: Да, согласен. Я это к чему? Моим проектом может стать компилятор с ассемблера Intel. Сможешь в этом помочь?

Claude: Да, такая задача мне интересна и я смогу помочь.Да, такая задача мне интересна и я смогу помочь. Но прежде чем сказать "погнали" — стоит честно разобрать, что значит "написать ассемблер с нуля", и где я буду полезен, а где придётся осторожнее.

Что нужно для x86/x64 ассемблера: Это значительно сложнее чем любой "обычный" компилятор языка типа C, потому что сложна сама целевая архитектура, а не язык. Парсер ассемблера — простой. А вот encoder инструкций — это годы работы, если делать как у NASM/MASM/JWasm.

Основные компоненты: 1. Frontend (lexer + parser). Тут всё просто. Синтаксис Intel прямолинеен: mnemonic op1, op2, op3. Директивы db/dw/dd/dq, секции, метки, выражения. Поддержка equ, макросов, условных директив %if/%endif (если хочешь NASM-стиль) или IF/ENDIF (MASM-стиль). Пара недель работы. 2. Symbol table + linker-подобная функциональность. Forward-references, относительные адреса меток, секции (.text, .data, .bss), public/extern символы. Прямолинейно. 3. Expression evaluator. Константные выражения с метками (label1 - label2), операторы, разрядность (BYTE PTR, WORD PTR, DWORD PTR, QWORD PTR). Тут есть нюансы с тем, какой размер операнда выбирать когда непонятно. 4. Encoder инструкций — основная боль. И именно тут ассемблер становится монстром. Каждая x86 инструкция — это: Опциональные legacy prefixes (LOCK, REP/REPNE, segment override, 66h operand-size, 67h address-size). Опциональные REX prefix (для 64-bit, доступа к R8-R15, расширения регистров SSE/AVX). Опциональный VEX prefix (2-byte или 3-byte, для AVX/AVX2). Опциональный EVEX prefix (4-byte, для AVX-512: маскирование, embedded broadcast, opmask register, rounding control). Opcode (1, 2, или 3 байта). ModR/M byte (mod[7:6], reg[5:3], rm[2:0]) — кодирует регистры и тип операнда. SIB byte (scale[7:6], index[5:3], base[2:0]) — для memory operand с индексом. Displacement (1, 2, 4, или 8 байт). Immediate (1, 2, 4, или 8 байт). И каждый opcode имеет десятки encodings в зависимости от: Размера операнда (8/16/32/64). Является ли операнд регистром или памятью. Доступа ли к расширенным регистрам. Использует ли VEX/EVEX (зачастую одна и та же инструкция имеет legacy и VEX form — например MOVAPS и VMOVAPS). Specific encoding constraints (есть инструкции с обязательным 66h префиксом, есть с запрещённым и т.д.). Для масштаба: Intel SDM Volume 2 (Instruction Set Reference) — 5+ тысяч страниц мелким шрифтом. Описывает каждую инструкцию + её encodings. Реальный ассемблер должен корректно энкодить тысячи мнемоник. 5. Output formatter. ELF (Linux), PE/COFF (Windows), Mach-O (macOS), flat binary, INTEL HEX. С relocations, symbol tables, debug info (DWARF/CodeView). Где я могу реально помочь

Очень хорошо: Архитектура проекта — как структурировать код, где какие модули, какие промежуточные представления использовать, как делать таблицы инструкций data-driven. Frontend — лексер, парсер, симбол-таблица, expression evaluator. Это стандартные задачи. Encoder для распространённых инструкций — общеупотребительные mov, add, sub, jmp, call, push, pop, и далее SSE/AVX базовый набор. Я понимаю ModR/M и REX. Могу написать кодировщик для подмножества инструкций. Output ELF/PE — стандартные форматы, документированные. Тесты — генерация test corpus, сравнение output с эталонным NASM/yasm для верификации.

Средне: Полный VEX encoding — знаю как устроен (2-byte vs 3-byte form, поля mmmmm, vvvv, L, pp), но детали для каждой конкретной инструкции буду сверять с SDM. Могу ошибиться в специфичной инструкции. EVEX encoding — сложнее, поля {z}, {k1}, {er}, {sae}, broadcast {1to8/1to16}, EVEX.b bit с double meaning. Концептуально знаю, но в реальном коде стоит сверяться с SDM. Macro system — особенно если ты захочешь NASM-style preprocessor с %macro, %rep — это уже мини-язык.

Плохо / опасно: Все edge cases — у x86 много инструкций с легасийными квирками. MOVS/SCAS с repe/repne, XCHG с lock, JCC short vs near, LEA с разными формами, NOP multi-byte варианты для alignment. Я знаю про большинство, но могу что-то упустить. AVX-512 corner cases — disp8 compressed displacement scaling, VSIB encoding для gather/scatter, mask register 0 vs k0, multi-byte EVEX opcodes. Это где я точно буду делать ошибки без сверки.

Исторические quirks — какой-нибудь AAM/AAD с непосредственным операндом, INTO, BOUND (которых нет в long mode), сегментация — мелочи которые в реальном коде встречаются раз в год, но ассемблер обязан их корректно генерировать.

Что я бы предложил: Не делать "полный NASM с нуля" — это годы работы для одного человека. Делать subset, который покрывает 95% реальных задач:

Stage 1 — minimal viable assembler: x86-64 only (без 16-bit и 32-bit mode).

Linux ELF64 или Windows PE64 output (одну платформу для начала).

Integer ISA + x87 + SSE/SSE2 (~300 mnemonics).

Базовые директивы: db/dw/dd/dq, label:, section, global, extern.

Без макросов и условных директив (потом).

Этого хватит чтобы запускать осмысленный код. Реалистичный объём для одного — 3-6 месяцев.

Stage 2 — расширения: AVX/AVX2/FMA3 + BMI1/BMI2.

Макросы и условные блоки. Релокации, статическая линковка с системными библиотеками.

Stage 3 (опционально): AVX-512. COFF, Mach-O. Debug info (DWARF/CodeView).

Стек: Если будешь писать на Delphi — задача нетривиальная, придётся самому писать TStringList-аналог, file I/O через WinAPI, hash tables.

Что мне нужно от тебя: Прежде чем начать — пара вопросов чтобы понимать масштаб:

Цель — учебный проект чтобы разобраться как устроен ассемблер? Или ты планируешь использовать его для чего-то реального?

Платформа output — Windows PE64 (логично с учётом target), Linux ELF64, или просто flat binary для начала?

Подмножество — целишься в "compatible с NASM по синтаксису" или хочешь свой синтаксис (типа MASM-стиля или вообще что-то новое)?

Объём времени — это hobby на годы или хочешь за 3-6 месяцев получить рабочий subset?

Если ответишь — могу более конкретно сказать, как это лучше структурировать и где я буду максимально полезен. Задача интересная и абсолютно реальная — Fasm в своё время написал один человек (Tomasz Grysztar), но он гений и потратил годы.

Chenjesu: Цель: Это просто интерес.Цель: Это просто интерес. На самом деле мне не нужен такой компилятор. Но твой ответ мне не очень понравился. Если есть структура файла и есть опкоды инструкций с разными операндами, то в чём могут быть сложности?

Claude: Справедливое возражение, и я с ним согласен. Я перестраховался, и это вышло занудно. Давай прямее. Ты прав по сути: на минимальном уровне ассемблер — это табличный transpiler. Мнемоника + операнды → байты. Никакой высокой сложности там нет, если операнды простые (регистр, immediate, прямая память).

Что реально нужно для базового x86-64: Таблица: для каждой мнемоники список её forms. Каждая form = (типы операндов, opcode bytes, ModR/M template, нужен ли REX.W). Парсер находит подходящую form по типам операндов. Энкодер собирает байты по template. Всё. Для условных 200 базовых инструкций (mov, add, sub, mul, div, jmp, jcc, call, ret, push, pop, lea, cmp, test, and, or, xor, shl, shr, неск. SSE/AVX) — это пара тысяч строк кода и таблица на пару тысяч записей. За пару недель реально написать первую рабочую версию которая ассемблирует осмысленные программы. Сложности, которые я перечислял, по факту делятся на две категории: Реальные: ModR/M + SIB кодирование адресов памяти. [rax+rcx*4+disp] — это не один байт, это нужно правильно собрать mod/reg/rm + scale/index/base + displacement (1 или 4 байта). Forward references меток (двухпроходный ассемблер). REX prefix когда есть R8-R15 или 64-битный operand. Это всё известные алгоритмы, описаны в Intel SDM Volume 2 главы 2.1-2.2 — десятки страниц, не тысячи. Воображаемые на старте: AVX-512 EVEX, macro preprocessor, debug info, Mach-O — всё это нужно только если ты их явно хочешь. Базовому ассемблеру они не нужны. Я в прошлом ответе свалил всё в кучу, как будто без AVX-512 и DWARF ассемблер не ассемблер. Это не так. Сделать рабочий subset для x86-64 integer + базовый SSE — реальная задача обозримого объёма. Так что давай к делу. Раз цель — интерес, и ты не торопишься с production, я бы предложил такой план:

Минимум, который даёт удовлетворение: Парсер Intel-синтаксиса (несколько сотен строк). Symbol table с двухпроходной резолюцией меток. Encoder для integer ISA (~150 базовых инструкций). Memory operand encoder (ModR/M + SIB + REX) — самая интересная часть. Output flat binary или минимальный PE64. После этого — добавление инструкций тривиально, просто новые записи в таблицу. Скажи, с чего хочешь начать — со структуры таблицы инструкций, с парсера, или с ModR/M encoder'а (это сердце дела)? И какой формат output для начала — flat binary (чтобы дизассемблировать через ndisasm и проверять корректность) или сразу PE64?

Chenjesu: Дело в том, что я привык экономить место и строки. То есть для меня важен объём полезной информации на странице. Ни один, известный мне компилятор, не позволяет в одной строке писать несколько инструкций. Вот и возникла мысль сделать компилятор, похожий на MASM, но такой, который бы понимал несколько инструкций в одной строке.

Claude: Хорошая идея, и она реализуется намного проще чем полный ассемблер с нуля.Хорошая идея, и она реализуется намного проще чем полный ассемблер с нуля. По сути ты описываешь препроцессор для уже существующего ассемблера, либо тонкий слой в собственном ассемблере. Давай разберём оба пути.

Путь 1: препроцессор (1-2 дня работы) Ты пишешь утилиту, которая берёт твой исходник с многострочными инструкциями и выдаёт нормальный MASM/NASM-совместимый файл. Дальше его компилирует штатный ассемблер. Логика тривиальная: mov rax,1; xor rbx,rbx; add rcx,rdx

Разделитель — ;, или что ты выберешь. Сложность: ; в MASM/NASM — это комментарий. То есть ты не можешь использовать ; как separator если хочешь оставаться синтаксис-совместимым. Варианты:

| или \\ — никем не используется в asm, безопасно.

:: или @@ — необычно, легко искать в коде.

; как separator + // как комментарий — твой синтаксис, но больше не совместим с MASM/NASM напрямую.

Препроцессор пишется буквально за вечер: читаешь строки, разбиваешь по separator, выводишь по одной на строку. Внимание к строковым литералам — "abc|def" не должно бить. Внимание к комментариям — после комментария до конца строки не разбивать. Всё. Это решит твою задачу сразу, без написания собственного ассемблера. И никаких потерь в функциональности — все мощные фичи MASM/NASM остаются.

Путь 2: свой ассемблер с этой фичей: Если хочешь именно свой ассемблер (по любым причинам — учебная, контроль, удовольствие) — multi-instruction per line добавляется к парсеру бесплатно. Это не отдельная фича, а просто свойство токенизатора.

В обычном ассемблере парсер работает так: читать строку → распарсить как одну инструкцию → emit С multi-instruction: читать строку → распарсить серию инструкций разделённых separator → emit каждую. Дополнительная работа в парсере — минут на 10. Куда более интересный вопрос — какой будет твой синтаксис в целом.

Что бы я предложил по синтаксису: Раз у тебя есть свобода дизайна, стоит подумать о том, что ещё в MASM раздражает занимает место. Вот несколько идей:

1. Несколько инструкций через ; — основная задача. mov rax,1; mov rbx,2; mov rcx,3

2. Сокращённые объявления данных. В MASM db 1,2,3,4 уже компактно. Но размещение строки + длины — обычно две инструкции:

msg db "Hello",0

len equ $-msg

Можно одной директивой:

msg dz "Hello" ; авто-добавление 0 + len = $-msg-1

3. Inline labels.

В обычном asm метка занимает строку: loop1: dec rcx jnz loop1

Можно так: @loop1: dec rcx; jnz @loop1

То есть label: в начале строки — нормально, но и @name: встроенно тоже работает, если для тебя это удобнее.

4. Compact register lists.

В MASM множественный push: push rax push rbx push rcx push rdx

Можно так: push rax,rbx,rcx,rdx ; разворачивается в 4 push'а

pop rdx,rcx,rbx,rax ; в обратном порядке для симметрии

5. Inline комментарии: Если уж жертвуешь ; в пользу separator — комментарии нужны другим способом. // (как в C++) или # (как в Python/shell). // приятнее на глаз.

mov rax,1; mov rbx,2 // инициализация счётчиков

6. Default operand sizes. В MASM нужно писать BYTE PTR [rax], DWORD PTR [rax] для разрешения неоднозначности. Можно ввести префикс размера прямо к скобке:

• b[rax] ; вместо BYTE PTR [rax]

• w[rax] ; вместо WORD PTR [rax]

• d[rax] ; вместо DWORD PTR [rax]

• q[rax] ; вместо QWORD PTR [rax]

• 7. Числовые литералы.

MASM требует суффиксы (100h), NASM позволяет префиксы (0x100). Можно поддержать оба + 0b для двоичных и 0o для восьмеричных.

Если главная цель — компактный синтаксис для собственного использования, я бы начал с препроцессора. Это решает 90% задачи за 5% усилий. Потом, если понравится — можно расширять (добавлять свои compact-фичи поверх MASM-syntax).

Если цель — ещё и интерес "как устроен ассемблер изнутри" — пиши свой. Multi-instruction per line там бесплатна, а параллельно разберёшься с ModR/M, REX, encoding и всем интересным.

Что тебе ближе? И есть ли уже представление о том, какой синтаксис ты бы хотел в целом — ближе к MASM, ближе к NASM, или вообще свой?

Chenjesu: Препроцессор - это не просто обёртка вокруг одного из компиляторов, но ещё и костыль. То есть мне придётся писать код, который не подсвечивается и не контролируется LSP? Так не интересно. Это всё равно, что писать код вслепую и проверять только при компиляции.

Claude: Согласен полностью. Препроцессор без IDE-поддержки — это шаг назад в эргономике. Написать свой компактный синтаксис, чтобы потом на нём кодить в Notepad и узнавать об ошибках только в момент сборки — никакой выгоды. Тогда только полноценный ассемблер, и подход правильный — нужно делать так, чтобы редактор понимал твой синтаксис как родной. Это не маленькая деталь, это половина успеха проекта.

Что нужно для нормальной IDE-интеграции: Чтобы код читался и валидировался на лету, тебе понадобится одно из двух:

1. Своё расширение для редактора. Самый мощный путь. Делается в формате LSP — Language Server Protocol. Ты пишешь сервер, который умеет: Tokenize → отдавать syntax highlighting (semantic tokens). Parse → находить ошибки синтаксиса в реальном времени. Знать таблицу инструкций → подсказывать допустимые операнды (completion). Резолвить метки → goto definition, find references. Показывать hover info: при наведении на инструкцию — её описание, encoding, latency/throughput. Хорошая новость: LSP — это JSON-RPC через stdin/stdout. Никаких хитрых интеграций. Один сервер работает в VS Code, Sublime, Vim, Emacs, JetBrains IDE, Helix — везде. Объём работы: базовый LSP (highlighting + ошибки + completion) — пара недель если язык простой. Для ассемблера он простой, парсинг тривиальный. Поэтому работа не больше чем для самого ассемблера. Бонус: компилятор и language server могут шарить parser/lexer/symbol-table код. Пишешь один раз, используешь в обоих. Это и архитектурно правильно — компилятор это batch-режим того же анализа, что LSP делает инкрементально.

2. TextMate grammar + extension с диагностикой. Чуть проще, но менее мощно. TextMate grammar (regex-based) даёт highlighting во всех современных редакторах. Дополняешь VS Code extension'ом, который запускает твой компилятор в watch-режиме и парсит его output как diagnostics. Минус: нет real-time analysis, нет smart completion (regex grammar ничего не знает про семантику). Только подсветка цветом + ошибки от компилятора с задержкой. Что я бы предложил для твоей ситуации: Раз ты целишься на comfort-level хорошего IDE — делай LSP сразу, с самого начала.

Core library — общая. CLI assembler читает файл и эмитит бинарь. Language server держит файл в памяти, переанализирует при каждом edit, шлёт diagnostics клиенту-редактору.

Это значит: с первого дня ты пишешь код в нормальной IDE с подсветкой и ошибками. Никакого "сначала компилятор, потом IDE-поддержка". Они растут вместе.

Минимальный стек для старта: Lexer. Токены: identifier, number, register-name, punctuation, string, comment, instruction-separator. Пара сотен строк. Parser. AST с типами: Instruction(mnemonic, operands), Label(name), Directive(name, args). Парсит по одному statement, separator (; или что выберешь) дробит строку на несколько statements. Тоже несколько сотен строк. Symbol table. Имена меток + их адреса. Forward references через два прохода. Instruction table — самое важное. Data-driven: для каждой инструкции описание её forms. Например:

• {mnemonic: "MOV", operands: [GPR64, IMM64], opcode: [B8+r], rex_w: true, imm_size: 8}

• {mnemonic: "MOV", operands: [GPR64, GPR64], opcode: [89], modrm: true, rex_w: true}

• {mnemonic: "MOV", operands: [GPR64, MEM64], opcode: [8B], modrm: true, rex_w: true}

• {mnemonic: "MOV", operands: [MEM64, GPR64], opcode: [89], modrm: true, rex_w: true}

Можно держать в коде как массив записей, можно во внешнем JSON/CSV/собственном формате. Преимущество JSON — легко обновлять без перекомпиляции компилятора.

Encoder. Получает выбранную form + операнды, эмитит байты. ModR/M encoder (~50 строк), SIB encoder (~30 строк), REX encoder (~20 строк), opcode + immediate emitter — всё.

Output. Сначала flat binary (просто байты в файл) — для тестирования через ndisasm или objdump -D -b binary -m i386:x86-64. Потом PE64 — это около 500 строк boilerplate (DOS stub, PE header, sections), документировано до байта.

LSP server. Тонкая обёртка над core library. Принимает textDocument/didChange, перепарсивает, отдаёт textDocument/publishDiagnostics. Hover, completion — добавляются по мере надобности.

Один пункт, который стоит решить заранее: Синтаксис — твой собственный или MASM-совместимый?

Свой: полная свобода, но никакая существующая документация и примеры не работают. Ты будешь сам всё писать. MASM-compatible с расширениями: существующие туториалы и примеры из интернета работают с минимальными правками. Твои compact-фичи — поверх. NASM-compatible с расширениями: аналогично, но синтаксис чище (по моему вкусу). Совместимость с одним из существующих — большой плюс на старте. Ты сразу можешь компилировать и тестировать существующие куски кода.

Требуется новая среда разработки. Которая позволит с приемлемой скоростью разрабатывать программы под Windows. Потому что “каноническим способом”, рекомендованным Microsoft, программа в одно окно содержит до трех тысяч строк кода и требует, соответственно, месяц работы. (В то время как на Паскале с использованием Turbo Vision программу с парой окон можно сделать за день. Но - только под DOS.)

Судя по всему, Борланд серьезно занялся направлением быстрой разработки под Windows, и в 1992 выпустил Object Vision - инструмент для разработки несложных приложений под Windows. Там окно можно было собрать мышкой из стандартных элементов буквально за полчаса. Вот только работало медленно, и в плане разрабатываемого функционала было чрезмерно скромно. Поэтому не пошло. Тем более, что и стоимость была - 495 долларов. Это вам не 49 баксов за Турбо Паскаль! Пользователи громко роптали. Цена была уменьшена до 250 долларов. Но это не помогло.

Я помню растерянность и разброд среди программистов Паскаля тех лет. Кто-то переходил на C, чтобы научиться писать под windows. Кто-то использовал только что появившийся Visual Basic, поскольку он позволял что-то сделать под Windows. Кто-то вообще уходил из программирования. Один мой друг занялся администрированием Юникса, и с тех пор к программированию так и не вернулся.

На рынке средств разработки СУБД воцарился MS Fox Pro, сначала в DOS-версии, а с января 1993 - под Windows, называясь теперь уже Visual Fox Pro. 

1995 Возвращение джедая

Давным-давно, в далекой-далекой галактике...
В 1993 году команда Андерса Хейлсберга
начала разработку нового языка
и новой интегрированной среды.
В 1995 разработка была завершена и продукт вышел на рынок.

В 1995 Borland выпустил в продажу новый продукт - Delphi 1.0.
За скромные 49.95 долларов.
Что это такое - поняли не сразу.

В первую очередь - это была интегрированная среда разработки под Windows.

В которой те самые окна, называемые формами, делались очень легко. Одним пунктом меню создаем пустую форму, умеющую все, что должно уметь приличное окно.
А теперь из палитры инструментов - вон там, вверху-справа - выбираем элементы управления - кнопки, строки ввода, галочки, меню и т.п. - и кладем на форму. И в инспекторе - вон, слева табличка - настраиваем свойства элемента.

Т.е. форму (окно, диалоговое окно) мы собираем мышкой. Минуты за три можно собрать окошко. (Ну, если стараться, чтоб было красиво и удобно - то дольше, конечно).

Этот способ собирания приложений мышкой получил специальное название - RAD (Rapid Application Development).

У Microsoft такое тоже было. В флагманских продуктах того момента - Visual Basic и Visual Fox Pro. С существенными отличиями, а именно - элементы управления, используемые Basic и Fox, надо было разрабатывать отдельно, на С, по технологии COM, что требовало особых знаний и навыков.
В Delphi же эти компоненты делались на том же Паскале, что и прочие программы, и даже начинающий программист мог доработать компонент под себя, унаследовав от него свой компонент и дописав к нему нужное. Но в комплект входило и отдельное руководство по разработке компонентов.
Поэтому впоследствии программистами были написаны сотни, если не тысячи разнообразных компонентов под Delphi.

И да, это была среда с универсальным высокоуровневым языком, т.е. сделать мы тут можем примерно все что угодно, а не что-то заранее регламентированное и жестко ограниченное , как в DBase и FoxPro.

А еще - тут был механизм доступа к базам данных. Причем, не к каким-то конкретным, а практически к любым. Для конкретной СУБД нужно было только написать драйвер, вызывающий ее функции.
А сама программа практически не зависела от используемой СУБД. И вот это было действительно мощным шагом вперед! Как и использование языка SQL. Который тут тоже можно было использовать универсально. Как для доступа к клиент-серверным СУБД, так и для работы с файловыми типа DBase или Paradox.

В общем, новая среда разработки решала сразу несколько давно назревших проблем:

1. Быстрая разработка программ под Windows

2. Быстрая и удобная разработка визуальной части (разработка форм на основе RAD)

3. Работа с базами данных. Любых форматов!

Собственно, название Delphi содержало намек на Дельфийский оракул из греческих мифов, и на название флагмана СУБД того времени - Oracle (оракул). Мол, мы вашему оракулу тут целый город построили, располагайтесь.

Кстати, новая среда была достаточно скромна в требованиях. Я ее запускал на 386-й машине с 40 MHz процессором и 4 МБ памяти. Правда, работало очень медленно. Но в документации было честно указано - требуется 8 МБ.

Позже я попробовал, и убедился, что при 8 МБ памяти работает нормально, при 12 и выше - просто летает, а еще больше ставить вроде не имеет смысла - быстрее уже не становится, даже на 32 МБ.

В отличие от MS Visual Fox Pro, где было указано требование 4 МБ, но ни на 4, ни на 8 нормально работать было невозможно. Нормальная работа Visual Fox Pro начиналась при 32 МБ, что для того времени было ну ооочень много.

1995-96 Неожиданный поворот

Вот второй раз фирма Борланд делает прорывный продукт, сравнимый, наверное, с пулеметом Максима. Конкурируя с гигантской империей Microsoft. Вот чего можно было ожидать далее?

А далее, внезапно, в том же 1995 году Филипп Кан уходит с поста генерального директора. Причина - несогласие с членами совета директоров относительно направлений дальнейшего развития фирмы.
В конце 1996 Кан окончательно покидает Борланд и организует уже другие фирмы, занимаясь совсем другими вещами.

И вот это мне совершенно непонятно. При всем сложном характера Кана, это выглядит как если б после Курской Дуги и Сталинграда товарища Жукова сняли с командования.

Видимо, основателей фирмы достало воевать, и они решили пожить спокойно, и порулить фирмой как полагается, по правилам. И дальше мы увидим, что у них получилось.

В 1996 фирму Борланд оставляет и Андерс Хейлсберг. Уходит в Microsoft. Там он будет разрабатывать новую среду разработки и новый язык. C# и Visual Studio.
Вам когда-нибудь наниматель платил три миллиона долларов за то, чтоб вы устроились к нему на работу?

В 1996, меньше чем через год, вышла вторая версия Delphi. Выходит она в трех редакциях. Самая дешевая стоит 500 долларов. Самая дорогая - 2000.
Собственно, это практически перекрыло дорогу широкому распространению Delphi на западе. Учитывая, что Visual Basic в минимальных вариантах был доступен практически бесплатно в составе MS Office, неудивительно, что простые приложения с формами и базами данных делали на нем, а более серьезные… ну, в основном тоже на нем…

Похоже, что стратегия Кана, продававшего продукты дешево, работала лучше?

А Борланд через некоторое время заявляет, что средства разработки (Delphi, C++ Builder и прочие) отныне не являются для фирмы основным стратегическим направлением. Основным же направлением будут средства поддержки жизненного цикла разработки программ. Они даже сделали несколько интересных инструментов. Вот только ни один из этих инструментов не получил особой популярности, и ни один не прожил долго.

1996-2000 Продолжаем движение по прямой

Следующие несколько лет среда Delphi линейно развивается – появляются некоторые усовершенствования в редакторе и отладчике, но в коде сохраняются старые недоделки, и вообще возникает ощущение, что команде разработчиков не хватает то ли людей, то ли сил, и эта нехватка чувствуется  все сильнее.

Команда Delphi (все-таки это была хорошая, сильная команда!) еще делает какие-то шаги, вводит какие-то новшества. Появляется MIDAS - средство для разработки клиент-серверных программ трехслойной архитектуры, на какое-то время появляется OLE Enterprise - пакет для разработки распределенных корпоративных приложений на основе технологии COM/DCOM, и в следующих версиях исчезает без следа.

2000 и далее – метания

В 2003 появляется Kylix - среда для разработки под Linux. И через год-два исчезает. То есть разработчики еще несколько лет пользуются им, но новых версий уже не появляется.

InterBase в какой-то момент становится системой с открытым кодом. Вскоре выделяется клон, называемый FireBird, и команда, которая его поддерживает - он жив до сих пор, и до сих пор его можно приобрести бесплатно. Но сам Borland через некоторое время возвращается к платному InterBase, сильно отстающему от бесплатного клона и по функционалу, и по количеству неисправленных ошибок.

Далее также однократно засвечивается интересный продукт Bold for Delphi.
Он интересен тем, что программа строится на основе UML-модели. Исходя из той же модели строится структура базы данных и логика оперирования данными в БД- создание и удаление изменение объектов (CRUD).
Можно сказать это одна из первых ORM систем. Правда в практическом применении проявляет себя довольно слабо работает медленно и построение запросов осуществляется чрезмерно примитивно и потому неэффективно.

Позже появляется продолжение этой разработки - уже под .Net, называется ECO - Enterprise Core Objects. Позволяет очень быстро построить несложную программу, работающую с несколькими таблицами, автоматически построить базу данных для нее, автоматически построить формы для редактирования объектов и навигации по ссылкам.
Вот только запросы к БД строятся настолько неэффективно, что для практического применения система совершенно непригодна. И тоже существует она всего пару лет.

Microsoft тем временем выдает новую платформу для разработки, .Net. И программисты начинают переходить с Delphi на C# и Visual Studio. Сначала по одному, а с 2005-2010 - уже массово. .Net становится очень популярным.

Borland выпускает новую версию среды - с возможностью разработки под .Net. Вот только если в Delphi среду снабдили набором удобных компонентов, сделавших разработку программ быстрой и удобной, то теперь на это просто не хватило сил. И пользователям предложили использовать компоненты, использовавшиеся в Visual Studio - набор “Windows Forms”.
А в следующей версии его убрали, и вместо него предложили использовать библиотеку VCL.Net.

В общем, теперь поведение Borland по отношению к пользователям уже никоим образом не отражает политики совместимости со старыми версиями - наоборот, оно скорее похоже на попытки шпиона оторваться от хвоста.
На мой взгляд, такие странности в поведении говорят о глубоком кризисе руководства и неспособности управлять процессом.

Эпилог

В конце двухтысячных годов остатки компании Borland были проданы компании Embarcadero, которая и сейчас продолжает продавать продукт Delphi.

Филипп Кан, уйдя из Borland, основал еще несколько фирм. Одну из них он продал компании Motorola за 325 миллионов долларов. Позже он занялся производством фитнес-браслетов. Похоже он в очередной раз угадал, на что будет спрос.

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

1. Запускаем текстовый редактор и пишем/правим текст программы.
   Сохраняем, закрываем редактор.

2. Запускаем транслятор (сейчас говорят компилятор), указывая в виде аргумента файл с текстом программы.
   Если в программе нет ошибок - получаем так называемый объектный модуль, содержащий алгоритмы нашей программы в машинных кодах, но без привязки к адресам в памяти.

3. Запускаем линкер (редактор связей), указывая ему файл(ы) с объектными модулями, он собирает их в готовую программу, устанавливая адреса для каждой переменной и каждой подпрограммы, и указывая эти адреса там, где эти объекты вызываются.
   Теперь программу можно запустить на выполнение.

4. Запускаем программу, проверяем, как она работает.

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

Запустив Турбо-Паскаль, ты работаешь в текстовом редакторе. И не выходя из него, можешь нажать одну клавишу - чтоб программа откомпилировалась и запустилась.
Завершив прогон программы - возвращаешься в редактор.

Если у тебя в тексте программы что-то не так - тебе не сообщают об этом. Не заставляют искать в тексте ту ошибочную строку. Тебя сразу автоматически отправляют на ту строку, где ошибка, остается только исправить ее.
В общем, если до этого задача “скомпилировать написанную программу” занимала неделю, то теперь это делалось за два часа.

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

В общем, на фоне привычных компиляторов Турбо Паскаль смотрелся как пулемет Максима среди дульнозарядных мушкетов. И было понятно, почему его так назвали. Также понятно, почему он получил такую популярность у начинающих программистов, а также преподавателей и студентов.

За его скорость и удобство ему можно было бы простить многое - даже если бы это был “игрушечный” компилятор, способный откомпилировать и собрать только маленькую учебную программу - популярность была бы ему обеспечена. А уж если этот инструмент мог создавать более-менее крупные программы с приличным качеством - его производитель, наверное, должен был бы озолотиться? Ну, давайте познакомимся с теми, кто это сделал.

1981 Основание фирмы Borland

Сама фирма началась с того, что в 1981 Нильс Енсен (Niels Jensen), Оле Хенриксен (Ole Henriksen) и Моргенс Глад (Mogens Glad)  основали компанию MIT - Market In Time.
Чем именно они будут заниматься - парни и сами пока не знали, они просто верили в персональные компьютеры, в свои силы и в свою удачу. И поначалу они просто писали программы для малых машин под управлением ОС CP/M.

В 1982 они посетили выставку CP/M-82, проходившую в Сан-Франциско. И сделали вывод, что если они хотят продавать свои программы в США - им надо иметь американскую компанию, располагающуюся в США, а не в Ирландии.

Кан-варвар из дикого леса

А еще они познакомились с Филиппом Каном. Который в то время имел хулиганские склонности, ездил на мотоцикле, играл на саксофоне, имел высшее образование в области математики и оконченную консерваторию, жил в США нелегально, поскольку не имел грин-карты… Зато он очень хорошо представлял, чем он хочет заняться для того, чтоб заработать денег.
Так что наши три датчанина приняли его в свою фирму. И саму фирму переназвали. Вроде как именно Кан предложил название Borland, означавшее на кельтском “лесная страна”.

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

Одна из статей о нем (к тому времени уже директоре Борланда, богатом и знаменитом) так и называлась - “Кан-Варвар” (Kahn the Barbarian).

Доли капитала в Borland были распределены так: Niels Jensen (250,000 акций), Ole Henriksen (160,000), Mogens Glad (100,000), and Kahn (80,000). Т.е. вроде как младший партнер. Филипп Кан становится президентом и генеральным директором (CEO) фирмы Borland, и в этой должности он будет 12 лет, до 1995.

1983 Появление Turbo Pascal

А идея у Кана была, собственно, в том, чтоб сделать удобную среду разработки. И еще хотелось быстрый компилятор, чтоб не приходилось идти курить, пока он пережевывает текст твоей программы.
В сущности, тут вроде ничего нового или революционного не было. Эта идея носилась в воздухе. Да, собственно, уже существовавший к тому времени Бейсик можно считать воплощением этой идеи. Но у Кана это действительно получилось, и получилось так хорошо, что его вариант стал по сути образцом для всех будущих.

Итак, в 1982 Кан начинает двигать свое направление, и находит талантливого программиста, тоже увлеченного этой идеей. А самое главное - этот программист уже сделал свою версию компилятора Паскаля под ОС CP/M. Теперь они начинаю делать Паскаль под MS DOS, и не просто компилятор, а именно среду разработки. И в 1983 у них выходит первая версия.

1982 В Borland приходит Андерс Хейлсберг (Anders Hejlsberg), разработчик Blue Label Pascal.

1983 Выпущена первая версия Turbo Pascal.

Название хорошо отражает основную суть. Компилятор был очень быстрым. У нормальных людей компиляция программы занимала от 5 минут до получаса, в Турбо Паскале же компиляция занимала не более 5 секунд. Надо сказать, Борланд всегда отличалась меткими названиями.

Новый продукт предполагалось продавать учебным заведениям. По недорогой цене. $49.99. При стоимости нормальных профессиональных компиляторов порядка $300.

Емкость рынка в первом приближении оценивалась в 30 000 потенциальных покупателей. Ну, т.е. если все они купят новую программу, то фирма получит полтора миллиона долларов. В реальности, естественно, купят далеко не все.

В реальности в первый месяц продаж Борланд набрал 3000 покупателей. Соответственно, 150 000 долларов.
Местные банки даже стали отказываться оплачивать чеки и кредитные карточки, подозревая компанию в мошенничестве.

Через два года (1985) журнал Байт сообщил о “поразительной для компьютерного языка цифре” в 250 000 экземпляров. (Т.е. в 8 раз больше максимальной первоначальной оценки!)
Это 12 с половиной миллионов долларов. Определенно, это был оглушительный успех!
Еще через полгода цифры достигли 400 000 проданных экземпляров и, соответственно, 20 миллионов долларов.

1985-1990 Рост и развитие

Последующие годы фирма активно развивает направление средств разработки. Появляются несколько языков со знакомой средой разработки - Turbo Basic, Turbo Assembler, Modula 2, Turbo Prolog, Turbo C (позже Borland C).
Идет активное соревнование с Microsoft в этой области, до середины 90-х.

В 1990-92 в Паскале появляется объектно-ориентированное программирование. И следом - объектно-ориентированная библиотека Turbo Vision, предназначенная для разработки современных (на то время) программ с окнами, меню, контекстной гипертекстовой подсказкой и т.д.

В Turbo Vision содержится красивая стройная концепция управления окнами, элементами окна, проверки вводимых в окно данных, взаимодействия элементов. В результате разработка таких программ становится намного проще и быстрее. В то же время сам Turbo Vision мог служить прекрасным примером - что такое ООП, зачем оно нужно, и как его применять. Многие программисты на нем учились, несколько программистов пытались сделать из него графический пакет. Одна из крупнейших программистских фирм нашего города продолжала писать программы с использованием Turbo Vision аж до начала 2000-х, когда уже всюду стоял Windows.

Cобственно, на том же Turbo Vision была сделана новая интегрированная среда Turbo Pascal 6.0. Это характерный для Borland подход - самим пользоваться тем, что они разрабатывают на продажу. При таком подходе продукт действительно получается удобным и качественным, потому что разработчик сам видит, что в его изделии удобно, а что можно улучшить, и он же имеет все средства чтоб улучшить его. Наверное, именно поэтому все продукты Борланда отличаются высоким качеством и удобством.

Кроме того, развиваются еще несколько продуктов совершенно других направлений:
Eureca - пакет для решения дифференциальных уравнений;
SideKick - нечто вроде пакета офисных программ, включая текстовый редактор, календарь, калькулятор, адресную книгу и телефонный номеронабиратель;
Quattro Pro - электронная таблица.

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

Конкурируют с Microsoft в области языков разработки. Надо сказать, достаточно успешно. Аж до конца 90-х. (И даже, пожалуй, до конца 2000х, но это уже другая история.)

Осваивают область разработки баз данных, в которой на то время катастрофически не хватает нормальных языков разработки алгоритмов и весьма бедно по части средств ввода данных. Тут Борланд предпринимает несколько крупных шагов, невзирая на затраты.

Приобретается Ansa Software и ее СУБД Paradox. Через некоторое время появляется выделенный пакет библиотечных функций Paradox Engine, который можно использовать для работы с Парадоксовскими таблицами из программ на C и Паскале.

В 1991 покупается Ashton-Tate - производитель знаменитого DBase. А значит, надо либо как-то объединить эти два продукта - DBase и Paradox - в одну концепцию, либо они будут конкурировать между собой, съедая деньги фирмы.

(Помимо этого, Ashton-Tate на тот момент владеет еще одной СУБД - InterBase, это уже полноценный сервер баз данных, работающий в клиент-серверной архитектуре, поддерживающий большие СУБД и способный на тот момент конкурировать с недавно появившимся MS SQL Server. Но работать с ним надо уже принципиально по-другому, не так, как с DBase и Paradox: если первым надо давать команды типа “перейди на следующую запись”, “удали запись”, “прочитай поле Х текущей записи” и т.п. - то взаимодействие с InterBase полностью основано на отправке SQL-запросов, которые уже выполняются этим сервером БД, при необходимости посылая в ответ небольшую порцию данных. Т.е. совсем другая логика построения программы, другие возможности. Можно сказать, что DBase и Paradox - это “игрушечные” СУБД, упрощенно реализующие функции работы с таблицами на уровне файлов; InterBase же - уже вполне “взрослая” СУБД, работающая по современным стандартам и сравнимая по возможностям с ведущими на то время Oracle, DB/2, и пытающимся дотянуться до них MS SQL Server.)

Кан пытается объединить направление языков разработки и направление баз данных, команду Turbo и команду DBase, но это ему не удается. Слишком разные команды, слишком много людей, слишком много функционала нужно объединить и привести к какому-то общему знаменателю. Это в конце концов приводит к финансовым проблемам и вынужденным сокращениям персонала в начале 90-х.

Microsoft же активно включается и в это соревнование, приобретя Fox Software и его Fox Pro - клон DBase, который он далее много лет развивает. (Параллельно разрабатывая MS SQL Server и MS Access)
В общем, в области разработки СУБД у них идет конкуренция, сравнимая с Курской Дугой…

А еще один фронт конкуренции разворачивается в области офисных пакетов. Microsoft начинает продвигать свой MS Office. Borland заключает соглашение с Word Perfect и начинает разработку и продвижение Borland Office, включающих в себя текстовый процессор Word Perfect и электронную таблицу Quattro Pro.

Надо сказать, меня удивляет то, что Borland, при несопоставимости размеров, мало того что конкурировал с Microsoft - он в некоторых сферах еще и конкурировал более успешно!

(продолжение следует)