curl уязвим, но я вам не скажу, какие версии

препроцессор Си => препроцессор асма => асм => линкер

Так можно сказать про любой компилятор.

Огромное количество артефактов сишки вызвано именно тем, что это просто-напросто нашлёпка над асмом, в том числе нуль-терминированные строки были родными для асма PDP

Это все не делает ЯП низкоуровневым. PDP давно стал историей, но нуль-терминированные строки до сих пор здесь, хотя ни для x86 ни для ARM они не являются чем-то родным. А сишку, тем не менее, зачем-то продолжают ставить в один ряд с асмом.

паскаль было жавой своего времени, максимально платформонезависимым ЯП с настолько безопасной памятью, насколько было приемлимо для того времени

Единственное средство защиты памяти, которое было тогда в рантайме у паскаля – контроль выхода за границы массивов. Все. Принципиально не понимаю, что помешало ввести аналогичную фичу в C, кроме нежелания уподобляться «клятому паскалю».

FPC разрешает арифметику над Pointer, которую Delphi, если я не ошибаюсь, запрешает до сих пор (разрешена только типизованная).

Арифметика указателей через кастинг к LongInt была доступна даже в TP под DOS. Начиная с Delphi 2009 она ровно на том же уровне, что и в C.

CPU - универсальны. На GPGPU эффективно считать задачи с массовым SIMD. Что попало на них уже не запустишь. ASIC-и вообще делают под конкретную задачу. Максимум эффективности, минимум универсальности.

Более того, на CPU эффективно считать тоже SIMD — все эти красивые цифры с килопопугаями на сайтах бенчкарков сделаны именно при помощи симда. На GPGPU можно запустить что угодно, только бегать «что угодно» будет скорее всего медленнее, чем на CPU, плюс GPGPU аппаратно не подключен к другим устройствам, потому его ввод-вывод ограничен. Где-то там между ASIC и GPGPU есть еще FPGA, которые позволяют подстраиваться под задачу, отличную от массового SIMD — другое дело, что FPGA имеют еще меньше популярности, чем все перечисленные категории.

Звучит как эфир и торсионные поля. Есть ссылку на статью про такие вычислители?

Какие вычислители? FPGA? Я привел пример асиков для нейронных сеток, их ты можешь нагуглить, как и FPGA.

Так можно сказать про любой компилятор.

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

Единственное средство защиты памяти, которое было тогда в рантайме у паскаля – контроль выхода за границы массивов. Все. Принципиально не понимаю, что помешало ввести аналогичную фичу в C, кроме нежелания уподобляться «клятому паскалю».

В паскале не было указателей — были ссылки, что ограничивало возможности, но в том числе возможности написать кривую программу. Между прочим, именно отсутствие ссылок в Си было огромным препятствием для написания оптимизаторов.

Арифметика указателей через кастинг к LongInt была доступна даже в TP под DOS. Начиная с Delphi 2009 она ровно на том же уровне, что и в C.

Да, но ты должен был явно делать все касты, а тут с ходу плюсуешь к указателю на пофиг. Потому я и говорю, что современный паскаль пошел по пути слепого копирования C/C++.

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

Любой студиозус при написании курсача на тему «компиляторы» представал перед выбором: генерить непосредственно машинный код, или ассемблерный исходник. 90% выбирали второе. Просто потому что логичнее переложить часть работы на тех, кто все уже сделал.

В паскале не было указателей — были ссылки

Чего, б….ь? Какие такие ссылки в Паскале? От первых Паскалей до реальных ссылок Delphi путь, длинною в жизнь.

современный паскаль пошел по пути слепого копирования C/C++

А что ему оставалось делать? Темплейты, дженерики, лямбды – все это взято от современных языков и тенденций. И пусть хейтеры скажут, что Pascal не развивается.

На паскале динамические списки с ссылками ещё в прошлом веке делались.

Любой студиозус при написании курсача на тему «компиляторы» представал перед выбором: генерить непосредственно машинный код, или ассемблерный исходник. 90% выбирали второе.

Генерировать объектник из асма по сложности примерно сравнимо с генерацией корректной работы с регистрами и стэком. Именно потому, к слову, в Си по традиции интенсивнее применяется стэк, чем регистры — да, компиляторы развились, но некоторое наследие осталось, вроде вызова с переменным числом аргументов.

Я не знаю, когда у тебя там студент «представал», но сейчас выбор и вовсе легок — какой-нибудь LLVM/GCC/TinyCC в роли бэка — и ты избегаешь даже проблемы генерации асма, ты генерируешь простой платформонезависимый IR, а на выходе получаешь бинарь.

Чего, б….ь? Какие такие ссылки в Паскале? От первых Паскалей до реальных ссылок Delphi путь, длинною в жизнь.

Что за «реальные ссылки в Delphi»? В первом паскале были ссылки из коробки.

А что ему оставалось делать? Темплейты, дженерики, лямбды – все это взято от современных языков и тенденций. И пусть хейтеры скажут, что Pascal не развивается.

Template — подмножество инструментов обобщенного программирования, довольно узкое, это не «современные языки и тенденции», а вполне конкретный набор из C++ и Java. Именно потому я пишу, что это слепое копирование C++.

Вот вложенные функции в паскале были, когда C++ даже не было в зародыше, паскаль первым из статических ЯП реализовал вложенные функции. Конечно, это были еще не лямбды, поскольку их нельзя было вернуть из функции наружу.

curl 'http://wttr.in/'

Я не парюсь т.к. для моих сurl скриптов есть правила apparmor. Будет время, думаю навесить эти правила на все утилиты которые ходят в сеть.

нуль-терминированные строки были родными для асма PDP

Я не знаком с PDP ассемблером, но как-то сложно представить, как для ассемблера может быть «родным» любой формат строк. Он же байтами оперирует ну или словами максимум.

В паскале не было указателей

Я думаю никому уже не интересно что там было в оригинальном Паскале, все знают именно продукты фирмы Borland а в них указатели есть.

В PDP нет инструкций для работы со строками. В VAX-11 были.

Инкрементные/декрементные операции хорошо ложились на ассемблеры PDP-11/VAX-11

C-шный цикл для копирования строки ограниченного \0 для PDP-11

while( (*d++ = *s++) != 0);

можно было заменить двумя командами

1$:   movb (r0)+,(r1+)
      jne  1$

Вобщем ясно, притянули за уши. То есть система команд pdp-11 позволяла легко (без доп. кода) детектировать ноль в потоке байт, да, но не более того.

В PDP нет инструкций для работы со строками. В VAX-11 были.

Если это аналоги movsb scasb итд из x86 то это опять не то. Это низкоуровневые побайтные операции, из которых при желании можно сложить строковые функции.

Ещё в зависимостях глянул, почему-то от curl зависит ещё и feh, например

Это обеспечивает работу полезной фичи у feh. Когда надо быстро но с удобством глянуть какую-то картинку по URL, всё очень просто: feh https://....

А где libcurl статически прилинкована?

У меня не статически, у меня в роутере transmission.

Ясно. Что касается роутера, кстати, ещё интересно, какие впечатления по поводу того, что начиная с версии 4 трансмиссию основной разработчик, вернувшись после многих лет пассивного участия, переписал на плюсы? Или от стандартной либы уже и без того есть зависимости? Хотя, трансмиссии надо не абы-что, а C++17.

Я пользовался старой, самостоятельно патченной трансмиссией, не вижу преимуществ свежих версий.

Я не знаком с PDP ассемблером, но как-то сложно представить, как для ассемблера может быть «родным» любой формат строк. Он же байтами оперирует ну или словами максимум.

Гуглишь мануал по ихнему асму, не задаешь глупых вопросов. Их асм отличался от Си разве что платформозависимостью. Типы данных (арфиметика над указателями без проверок корректности) там были абсолютно такие же, как в Си. В асмах и тогда, и сейчас есть возможность задавать константы, а потом брать их адрес по имени идентификатора — это и есть сишные строки с массивами (именно поэтому в Си они внезапно являются указателями).

То есть система команд pdp-11 позволяла легко (без доп. кода) детектировать ноль в потоке байт, да, но не более того.

Что в ней должно было быть? Одна инструкция «скопировать 198 байт из одного регистра в другой»? В x86 есть аналогичная поддержка нуль-терминированных строк на уровне REPNZ. У тебя сравнение строки в две инструкции, копирование строки в две инструкции — что тебе еще нужно? Если добавить сюда еще асмовый препроцессор, то можно было реализовать strcpy в одну формальную инструкцию.

Производитель вообще не чешется, он просто делает минимальные правки к инструментам 30-летней давности.

Производителя чаще всего интересуют только деньги. А именно: сделать нужный продукт/функционал с минимальными затратами ресурсов. И чаще всего ему наплевать как оно потом будет работать. Сегодня «х**к и в продакшин» и потекли денежки. А если завтра если юзеры начнут вопить, то «посмотрим как это можно починить/улучшить костылями и подпорками».

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

В том и дело, что «поддержка каких-то там строк» - это не дело проца вообще. Это именно дело высокоуровневых языков. Потому меня и удивила фраза что это «строки из асма».

В x86 есть аналогичная поддержка нуль-терминированных строк на уровне REPNZ

Опять - это ни разу не поддержка строк. Это просто низкоуровневый цикл с поиском нуля. Для чего его будет использовать программист или компилятор - совсем другое дело.

что тебе еще нужно

Чтобы не перевирали терминологию.

Если добавить сюда еще асмовый препроцессор, то можно было реализовать strcpy в одну формальную инструкцию.

С препроцессором можно что угодно в одну якобы инструкцию засунуть, но это тут ни при чём.

Производителя чаще всего интересуют только деньги.

Именно это я написал где-то страницу-две назад, только в контексте надежности и уязвимостей. Самое смешное то, что всякие там мерседесы с поршами тоже экономят на спичках, и потом их глючные корыта по два раза в неделю приходится налаживать в сервисе.

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

Машинные код — это машинные коды, ассемблер — это ассемблер. Даже в 70-е годы мало кто писал на машинных кодах. Люди, которые монитор называют «системным блоком», обычно просто не знают, что такое ассемблер. Я никогда в жизни еще не общался с человеком, который употребляет слово «ассемблер» в роли «машинный код», ты будешь первым.

В том и дело, что «поддержка каких-то там строк» - это не дело проца вообще. Это именно дело высокоуровневых языков. Потому меня и удивила фраза что это «строки из асма».

Ну поздравляю, тогда Си тоже не поддерживает строки. Что, в общем-то, есть правда.

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

Нет смысла использовать код, 90% которого тебе не нужны

Разве компилятор не выкидывает неиспользуемый код? Даже для жаваскрипта родили tree shaking.

Нет, у Си есть синтаксис «строковый литерал», который неотъемлемая часть языка. Вобщем-то на этом его поддержка строк и заканчивается, да. Всякие strchr() итд это уже библиотека а не язык (хотя я знаю что графоманы из комитета смешивают эти два понятия). Кстати, никто не мешает сделать свою библиотеку с другим форматом строк (в т.ч. переопределив в ней тот же strchr), хотя литералы с ней использовать уже нормально не получится. Да и для общения с сисколлами придётся свой переходник организовывать.

Строго говоря, «ассемблер» - это сборщик, а язык правильно называть «язык ассемблера».

Разве компилятор не выкидывает неиспользуемый код? Даже для жаваскрипта родили tree shaking.

Если линкуется динамически, компилятор не будет вырезать что-либо из so’шки.

На паскале динамические списки с ссылками ещё в прошлом веке делались.

Динамический список в паскале испокон веков делался типизированным указателем. Для этого даже разрешили объявлять указатель на тип перед объявлением самого типа.

Я не знаю, когда у тебя там студент «представал», но сейчас выбор и вовсе легок — какой-нибудь LLVM/GCC/TinyCC

Не было тогда LLVM. А использование бэкенда GCC всегда было гемором похлеще непосредственной генерации COM-файла для DOS.

В первом паскале были ссылки из коробки.

Блин, что вы называете ссылками паскаля? Чем в вашем понимании ссылка отличается от указателя?

Именно потому я пишу, что это слепое копирование C++

Темплейты в delphi появились скорее под давлением C#, который в то время был основным конкурентом (стильным, модным, молодежным) и активно выдавливал делфю с рынка десктопов.

Вот вложенные функции в паскале были, когда C++ даже не было в зародыше, паскаль первым из статических ЯП реализовал вложенные функции.

Не понимаю, почему сишная братия так сохнет по этим вложенным функциям. Как по мне, довольно бесполезный сахарок, который к тому же часто используется во вред читаемости и отлаживаемости. Модули ИМХО были гораздо важнее и приятнее (особенно в те времена, когда один только stdio.h сходу удлинял компиляцию на десяток секунд).

посмотри в lwip стек, там и собственный менеджер памяти и списки и даже tcp/ip, и всё это вроде как fixed footprint.

Ни один адекватный человек не предлагает писать на асме все.

а кто-то на лоре предлагал писать всё на си?)

сишники гнобят любые альтернативы и считают, что топорность и убогость языка обеспечивает

Ну раст мне вобще не понравился, был у нас на нём проект один. Мож он там от чего то и спасает, но ну его нафиг :) Про другие «альтернативы» си ничего сказать не могу.

а кто-то на лоре предлагал писать всё на си?

На ЛОРе достаточно людей, гнобящих все, кроме Си и крестов.

Машинный код это двоичное представление процовых команд, а ассемблер - текстовое, вот в целом вся разница.

Нет не вся разница, одна из первых выдач в гуглее:
https://habr.com/articles/423077/

; Компоновщик находит символ _start и начинает выполнение программы
; отсюда.
global _start

; В разделе .rodata хранятся константы (только для чтения)
; Порядок секций не имеет значения, но я люблю ставить её вперёд
section .rodata
    ; Объявляем пару байтов как hello_world. Псевдоинструкция базы NASM 
    ; допускает однобайтовое значение, строковую константу или их сочетание,
    ; как здесь. 0xA = новая строка, 0x0 = нуль окончания строки
    hello_world: db "Hello world!", 0xA, 0x0

; Начало секции .text, где находится код программы
section .text
_start:
    mov eax, 0x04           ; записать число 4 в регистр eax (0x04 = write())
    mov ebx, 0x1            ; дескриптор файла (1 = стандартный вывод, 2 = стандартная ошибка)
    mov ecx, hello_world    ; указатель на выводимую строку
    mov edx, 14             ; длина строки
    int 0x80                ; отправляем сигнал прерывания 0x80, который ОС
                            ;   интерпретирует как системный вызов

    mov eax, 0x01           ; 0x01 = exit()
    mov ebx, 0              ; 0 = нет ошибок
    int 0x80

А синтаксис объявления байтов с данными и подобного это в некотором роде тоже ассемблер, но он зависит больше от вкусов

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

Нет, у Си есть синтаксис «строковый литерал», который неотъемлемая часть языка.

А у асма синтаксис «строковая константа», которая неотъемлимая часть языка. И чо делать будем?

Если линкуется динамически, компилятор не будет вырезать что-либо из so’шки.

Кстати, та же проблема имеем место при отсутствиии Link Time Optimization. Почему я давно пишу, что раздельная сборка — это изначално путь вникуда, все современные ЯП приходят к тому, что половина сборки происходит после парсинга всего текста проекта.

не путать «раздельный» и «инкрементальный»

Блин, что вы называете ссылками паскаля? Чем в вашем понимании ссылка отличается от указателя?

В Паскале и правда есть ссылки - это передача аргумента через var. От указателей отличаются как минимум синтаксисом, а вообще может и внутренней реализацией (ссылки нельзя перезаписывать, это открывает доп возможности оптимизации).

Я не понял, как статья по ссылке является аргументом к нашему спору. Из предоставленного тобой листинга ассемблер - это только mov и int. Остальное - расширения над ним, которые не генерируют непосредственно никакой машинный код, и которые каждый (автор компилятора!) делает как хочет. В частности, этот исходник не скомпилируется tasm-ом, например. А если выкинуть весь побочный синтаксис (метку можно оставить) - скомпилируется. Из современных, насколько я знаю, есть gas, fasm, nasm - и у каждого свой несовместимый с другими синтаксис этих штук. А вот mov и прочее - зависят от платформы - это и есть тот самый x86-ассемблер в чистом виде. Для другого проца будут другие инструкции.

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

Видимо речь всё таки не про асм PDP, а про дефолтную его реализацию.

В том и дело, что у асма нет синтаксиса строковой константы. Есть только синтаксис объединения соседних байт в общие кавычки, строкой оно от этого не становится, никакие ни нуль-терминации, ни прочие способы указать длину само собой не добавляет. Это просто побайтовый дамп. Программист может с помощью побайтового дампа закодировать строку, да, либо добавив в конец ноль для ASCIIZ, либо добавив в конец знак доллара для строки к DOS int 21h/ah=9, либо добавив в начало байт количества символов для LSTRING которые приняты в Паскале, либо использовав любой другой способ по ситуации.

Блин, что вы называете ссылками паскаля? Чем в вашем понимании ссылка отличается от указателя?

Нет арифметики, нельзя просто присвоить-передать кому попало, только как значение, на которое ссылаются. Я подозреваю, что паскалевы ссылки были всё-таки наполовину свободными, но там точно не было такого бардака, как в Си, где с указателем можно делать что угодно.

Темплейты в delphi появились скорее под давлением C#, который в то время был основным конкурентом (стильным, модным, молодежным) и активно выдавливал делфю с рынка десктопов.

C# выдавливал делфю строго с виндовых десктопов, на остальных платформах про него не знали. С таким же успехом можно придумывать, что Electron давит на Delphi, Java давит на Delphi — все давят, все требуют идти в ногу со временем, потому что Delphi почти лет 15 стагнировал под руководством Borland, которая была почти с самого начала как царь Мидас, только превращало всё, к чем прикасается, в говно.

А помните вторую MVCC СУБД в индустрии после оракла? Я с ней работал — она где-то на уровне 80-х годов и осталась, еще когда оно было Groton Database Systems, а потом было продано Ashton-Tale, а потому уже в 90-х Borland-у — за всё это время она просто из рук в руки ходила и больше ничего с ней не происходило.

Естественно, когда ты нихера не делаешь, а твои конкуренты делают, то «под давлением конкурентов» рано или поздно придется либо что-то начать делать, либо уйти с рынка.

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

Написать код в том месте, где он будет исполняться по логической последовательности — это «вред читаемости и отлаживаемости»? Асинхронщину писал когда-нибудь? Или какие-нибудь переиспользуемые для разных задач контейнера и прочие алгоритмы.

Модули ИМХО были гораздо важнее и приятнее (особенно в те времена, когда один только stdio.h сходу удлинял компиляцию на десяток секунд).

Только в исходном паскале их не было, вместо этого делись те же инклуды.

Неограниченное применение сишных макросов привело к тому, что слишком много софта ломалось при отказе от классического механизма #include.

Нет арифметики, нельзя просто присвоить-передать кому попало, только как значение, на которое ссылаются. Я подозреваю, что паскалевы ссылки были всё-таки наполовину свободными, но там точно не было такого бардака, как в Си, где с указателем можно делать что угодно.

Нет, это всё-таки указатели. И в Паскале с ними тоже можно сделать что угодно, только синтаксис более громоздкий, но это (громоздкий синтаксис) вообще общее отличие Паскаля от Си.

Написать код в том месте, где он будет исполняться по логической последовательности — это «вред читаемости и отлаживаемости»? Асинхронщину писал когда-нибудь? Или какие-нибудь переиспользуемые для разных задач контейнера и прочие алгоритмы.

Да, вред. Не путай скриптоасинхронщину (всякие await, не помню из какого это языка) и Си. В Си асинхронщина делается в явном виде с конкретным кодом, который ждёт, создаёт если надо треды и что-то вызывает.

Только в исходном паскале их не было, вместо этого делись те же инклуды.

Исходный Паскаль все забыли ещё в 90-х. Паскаль это конечно Турбо-Паскаль (версии не меньшне 5.5 или 6.0 даже) и его наследники.

Из предоставленного тобой листинга ассемблер - это только mov и int. Остальное - расширения над ним, которые не генерируют непосредственно никакой машинный код

Они вообще-то генерируют «машинный код», причем, даже один в один указанные байтики.

А вот mov и прочее - зависят от платформы - это и есть тот самый x86-ассемблер в чистом виде.

Хах, гнушный асм применяет иной синтаксис и порядок записи операндов, так что я бы скорее говорил про диалекты.

Видимо речь всё таки не про асм PDP, а про дефолтную его реализацию.

А другой и не было.

И в Паскале с ними тоже можно сделать что угодно, только синтаксис более громоздкий, но это (громоздкий синтаксис) вообще общее отличие Паскаля от Си.

В Turbo Pascal — да. Но исходный паскаль был заметно более строгий, там даже преобразования типов не было, потому никаких инструментов даже для «громоздкого синтаксиса» там не было.

В Си асинхронщина делается в явном виде с конкретным кодом, который ждёт, создаёт если надо треды и что-то вызывает.

Асинхронщина, она же «кооперативная многозадачность», не создает хардварных тредов, а вместо этого добровольно передает управление другой задаче — и вот эту самую передачу управления и возобновление работы без замыканий больно реализовывать на голом Си. И в C++ тоже больно реализовывать без замыканий (async/await поздних стандартов тоже применяет механизм замыканий). Как ты собрался передавать данные из одного этапа в другой? Указателем void * на пользовательскую структуру, которая по сути является аналогом замыканий, или, еще хуже, через глобальную переменную.

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

Исходный Паскаль все забыли ещё в 90-х. Паскаль это конечно Турбо-Паскаль (версии не меньшне 5.5 или 6.0 даже) и его наследники.

Не забыли, из него сделали Java, но с синтаксисом из C++.

Они вообще-то генерируют «машинный код», причем, даже один в один указанные байтики.

Ну расскажи, какой такой машинный код генерирует строка section .rodata?

И строка hello_world: db "Hello world!", 0xA, 0x0 никакого машинного кода тоже не генерирует. Она действительно записывает байты, это это байты данных, а не кода. И даже если ты через db побайтово закодируешь инструкцию mov ah,9, то роль ассемблера в генерации данного кода будет практически никакая.

Хах, гнушный асм применяет иной синтаксис и порядок записи операндов, так что я бы скорее говорил про диалекты.

Он поддерживает и intel-синтаксис тоже. Но дело не в этом. x86-асм - это о том, что вот есть инструкция MOV и она поддерживает такие-то операнды. А уже реализации выбирают, как именно они эту инструкцию примут от юзера (программиста), в каком порядке и формате будут читать операнды, итд. Но вот команда (не инструкция) «DB» - никакой сущности в машинном коде не соответствует. Это просто указание ассемблеру принять дамп как есть.

А другой и не было.

Я и не сомневался. Ну ладно, возможно это была проблема взаимопонимания терминологии.

Асинхронщина, она же «кооперативная многозадачность»

По-моему тут опять расхождение в терминах. Кооперативную многозадачность я делал - на Турбо-Паскале + 16+32бит-асме (роутер с драйвером сетевухи, tcp/ip стеком и псевдографическим оконным интерфейсом, с простым шеллом, текстовым редактором для конфигов, телнетом и даже простым http-браузером) - всё в одном бинарнике и в одном «треде» выполнения. Как-то обошёлся без замыканий и прочего.

Как ты собрался передавать данные из одного этапа в другой?

Просто хранить состояние к каждому кооперативному «процессу»? В полях объекта, например. А если экземпляр строго один - в глобальных переменных.

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

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

Не забыли, из него сделали Java, но с синтаксисом из C++.

Нет, ООП в исходном Паскале тоже не было. А это центральная идея джавы. А вот в Турбо-Паскале начиная с 5.5 появилось.

Кооперативную многозадачность я делал - на Турбо-Паскале + 16+32бит-асме
Как-то обошёлся без замыканий и прочего.

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

Как ты собрался передавать данные из одного этапа в другой?

Просто хранить состояние к каждому кооперативному «процессу»? В полях объекта, например.

Можно даже вот так:
https://web.archive.org/web/20220917140844/http://swag.outpostbbs.net/MISC/01...
Можно что-то подобное даже на асме реализовать. Но до действительно простой и удобной асинхронщины там как до киева раком.

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

Это херота, а не фича, goto+глобальные переменные 70-х годов, которые стали неактуальными если не к 80-м, то к 90-м годам, поскольку в 80-х стало ясно, что основная сложность программирования — это недопустимо высокая сложность чтения и отладки лапшекода. В многих современных языках уже goto отсутствует в принципе, но некоторые до сих пор рассказывают про «с умом во благо».

Нет, ООП в исходном Паскале тоже не было. А это центральная идея джавы. А вот в Турбо-Паскале начиная с 5.5 появилось.

ООП само по себе не платформозависимо и не платформонезависимо. Turbo Pascal уже был приколочен гвоздями к x86 и требовал активного использования ассемблера. В то же время UCSD Pascal и промежуточное производное, Mesa, были вполне себе платформонезависимыми, выполняющимися на базе виртуальной машинки. Да, на эту платформу натянули число крестовое ООП (такого больше нигде не было) и сборщик мусора — это и есть Java, какой мы ее знаем.

сделать это на ЯП со встроенной асинхронностью проще

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

а на каком-нибудь Erlang/Go, где зеленые потоки на уровне рантайма

Erlang не видел. То как в Go принято - это ужас.

Можно даже вот так:

Это обычный многозадачный движок, такой же как в современных ОС, только несколько недоделанный. Осталось процедуру yield засунуть в обработчик системного таймера и будет обычная вытесняющая многозадачность. Не знаю зачем ты его в эту тему привёл. Понимание «кооперативной многозадачности» как «вызывайте почаще переключалку» (там такой коммент имеется) - по-моему, весьма упрощённое и представляет из себя на самом деле обрезанный вариант вытесняющей. Нормальная кооперативная многозадачность это как минимум event loop с легковесными обработчиками, который из коробки имелся в том же Turbo Vision (ну, надо учитывать что вся библиотека ориентирована исключительно на пользовательский интерфейс).

Можно что-то подобное даже на асме реализовать.

На асме тоже можно, разумеется, на нём всё можно.

Но до действительно простой и удобной асинхронщины там как до киева раком.

По итогу я так и не понял что ты считаешь асинхронщиной. У меня уже возникло подозрение что ты «кооперативная многозадачность» ошибочно используешь и надо опять искать что скрывается за этим термином.

стали неактуальными если не к 80-м, то к 90-м годам, поскольку в 80-х стало ясно

Модные тренды это к блоггерам. А программисты другим занимаются. То, что ты записал в минусы Си - показывает исключительно твоё непонимание зачем он нужен. Это не язык манипулирования данными, это язык выдачи инструкций процессору, и он даёт программисту полную возможность это делать.

ООП само по себе не платформозависимо и не платформонезависимо.

Я про то что «Джаву сделали из Паскаля» - в то время как центральной её идеи в Паскале не было, а вот в Турбо-Паскале - была.

натянули число крестовое ООП (такого больше нигде не было)

И где же в джаве перегрузка операторов? Где шаблоны до джавы5 в 2004 году? По-моему на С++ ООП ни разу не похоже. А вот на Паскалевское - вполне.