Умер сэр Клайв Синклер

«использовать» и «избежать» - диаметрально противоположные вещи.

Правильно: платформо-специфичные оптимизации за вас джит должен делать

Ты какой-то очень индоктринированный. Как за меня JIT сделает value-семантику? JIT/AOT умеют делать только микро-оптимизации. преобоазовывать операционную семантику, а уж тем более, выводить новую, они не умеют.

Пруфы, что уже входит - есть?

Конечно есть. https://github.com/llvm/llvm-project/tree/main/clang/examples/clang-interpreter

это касается квалификации программиста

Стоило поставить одну из нормальных операционок, тот же линукс или NT 3.51 - и много ли ваткомовских прог будут нормально работать под тогдашними их эмуляторами? :) Да и сейчас тормозят (а тогда просто не запускались).

Не помню таких проблем под виндой и os/2, в них было DPMI и расширятели в первую очередь это старались пользовать. Бывали, правда, и всякие экзотические поделки, вплоть до того, что с emm386 не хотели работать.
Про ваткомы толком не помню, они разве dos4gw не умели?

Все которые у меня были - работали без проблем, в целом ядро там вполне каноничное - же.

У спектрума например внутренний стек аккумулятора - 6 байт

Можно, пожалуйста, подробнее? Никогда не сльішал про особьій стек для аккумулятора. Что-то на уровне внутреннего железа Z80?

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

Стек калькулятора а не аккумулятора.

А внутренний стек проца это когда встраивают стек ну там 256 байт SRAM в проц., и он находится там а не в памяти.

В таком случае что означает число 6 байт? Размер стека задавался через системные переменные, а сами значения в нём - 5 байт.

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

5 байт это числа в коде basic программы.

И именно такими значениями оперировал стек. Кроме чисел умел ещё строки.

Размер стека калькулятора не задавался системными переменными, была только переменная хранившая в себе указатель вершины стека.

Начало и конец стека задавали две соседние переменные.

Нет только вершину задавал а низ(начало) был определено однозначно и сразу равно как и машинный стек.

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

(habr)

первые команды с адреса 0 spectruma

DI      //запрещение прерываний
Xor A
Ld HL, 62000 //пример
Ld SP, HL

Про 6 байт какого стека какого калькулятора ты говорил и к чему?

Понял. Меня слово «аккумулятор» ввело в заблуждение. Калькулятор - конечно же чисто софтовое решение. Я так до него не добрался, особо небьіло нужно и тогда он показался каким-то заумньім.

О гсподи, для всяких там операций арифметических в спектруме был калькулятор со своим стеком со своими опкодами.

https://hype.retroscene.org/blog/1007.html

DRAM. Даже регистры в процессорах того уровня - это DRAM.

Какой DRAM? это вообще не память это регистр защелка.

Он по сигналу ld записывает данные и это весь функционал.

Вот простейшая схема с таким 4-битным регистром, только один вход кроме входов данных https://tinyurl.com/yj66s9mo

Итить. Я тебя уже несколько сообщений подряд тычу в этот калькулятор и пытаюсь выяснить, про какие 6 байт ты говорил.

ну 5 байт может быть, что все заново объяснять?

Да нечего там объяснять, просто несешь какую-то бессвязную пургу невпопад.

Я не обязан тебе объяснять, я тебе ссылку дал чтоб ты взял и прочитал.

По сравнению с Агатами и Микрошами, даже первый MSX был чудесен. А уж второй так и подавно.

Конечно есть. https://github.com/llvm/llvm-project/tree/main/clang/examples/clang-interpreter

Речь шла про некий мистический джит в силанг. При чём тут интерпретатор то? Понятно, что интерпретатор будет использовать ллвмный джит. Но это к явовскому джиту или к оптимизации вообще никакого отношения не имеет…

Не помню таких проблем под виндой

Под какой именно? Там, где ntvdm стоял, ничего не работало. Если вы про винды серии 9х - там несколько иначе дело обстояло, но это не совсем «нормальная операционка» была. :) Она сама из ДОСа стартовала.

и os/2

В ос/2 действительно была весьма качественная поддержка ДОСа. А заодно и win16, только для этого надо было спец версию винды 3.1 запустить. Как я понял из форумов, dosemu2 пытается пойти по их стопам. Долго уже пытается…

в них было DPMI

Было. Только этого мало. :) Под NTVDM вы не запустите чуть более чем ничего, а DPMI там - есть. Зато толку нет.

Про ваткомы толком не помню, они разве dos4gw не умели?

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

Все которые у меня были - работали без проблем, в целом ядро там вполне каноничное - же.

Я про CP/M на спеках вообще не в курсе, если честно. Это была какая-то подточенная под железо CP/M, или взятая с моделей +3? Кто делал адаптацию?

Ты спросил, я показал. С++ можно JIT-ить. Это можно использовать здесь и сейчас. Я использую его в своем форке Clang для вызова метафункций во время компиляции. Ты можешь его использовать в своем приложении, если очень надо. И, да. Он делает все те же оптимизации, что и AOT-вариант.

Но, вот, ту же value-семантику, необходимую для эффективной эксплуатации локальности данных, тебе ни один JIT не сделает в программе, которая эту семантику не использует. А JVM-программы её использовать не могут, потому что в JVM нет такой семантики. Там всё выделяется в куче и ты никак этим не управляешь. Вообще.

Это всё не про оптимизации, а про про абстрактную модель машины, которая дается программисту. И JVM в этом плане весьма и весьма примитивна. Что не позволяет писать на Java высокопроизводительные приложения.

Ты спросил, я показал.

Но я не просил интерпретатор, а джит для него - в ллвме, а не в силанге.

Это можно использовать здесь и сейчас.

А что это даст? Это интерпретатор. Даже если он с джитованием, всё равно же очевидно, что исходник он будет обрабатывать крайне медленно, хотя бы по первому разу. В отличии от жвмного байт-кода, который уже скомпилен и оптимизирован. У вас что, есть пруфы, что этот интерпретатор ваш будет работать быстрее скомпиленного кода?

А JVM-программы её использовать не могут, потому что в JVM нет такой семантики. Там всё выделяется в куче и ты никак этим не управляешь. Вообще.

Это кто вам такое рассказал? В яве есть примитивные типы, и, соответственно, валуе-семантика для них.

Но я не просил интерпретатор, а джит для него - в ллвме, а не в силанге.

Я тебе показал именно то, что ты просил. LLVM и Clang — это один проект. Посмотри в репозитарий, если не веришь. Там есть ленивый JIT, который будет обрабатывать исходник инкрементно. Просто в том примере ленивый JIT не используется. Но нам никто не мешает его включить самим, что я, например, и сделал. Хотя пришлось посидеть и похакать.

JIT в LLVM гораздо мощнее, чем в JVM. Он просто не профилирующий, и не совсем JIT (долго стартует). Поэтому разные модные инерпретируемые язычки его не используют. Но зато для специализированных приложений (например, баз данных, или акселераторов) он генерит очень мощный код. Потому что вся мощь LLVM/Clang к нашим услугам. Ничего такого ты и близко не получишь с JVM-овским JIT-ом. Что-то примерно похожее можно выжать из Graal, но последний лет на 10 отстает от LLVM по охвату фич.

Это кто вам такое рассказал? В яве есть примитивные типы, и, соответственно, валуе-семантика для них.

А структуры? Как мне делать композитную value-семантику? Руками всё мапить на массивы? Ну, ок. Value-типы для бедных. Но оптимизатор про них не знает ничего.

Там есть ленивый JIT, который будет обрабатывать исходник инкрементно.

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

JIT в LLVM гораздо мощнее, чем в JVM. Он просто не профилирующий, и не совсем JIT (долго стартует).

Это всё не новости. Джит должен быть инкрементальный и профилирующий. Первый проход должен быть почти мгновенным, дальше уже можно собрать профайл, посидеть, подумать, переджитовать по-лучше. Но когда речь об интерпретаторе, тогда это всё вырождается почти в ту же статическую компиляцию, разве что происходит не сразу, а по частям. Что, наверняка, ещё сильнее ухудшает оптимизацию, так как интерпретируемый сейчас кусок не знает о том, что будет дальше. А без code/data flow анализа оптимизация толком не возможна. В общем, не пытайтесь меня убедить, что интерпретатор С++ - хоть с джитом, хоть без - может хоть каким-то боком соперничать с нормаьной статической AOT-оптимизацией, или с нормальной джит-оптимизацией уже заранее АОТ-прооптимизированного байткода.

Да это не важно. Когда один инклуд плюсового хедера тянет десятки мегабайт хедеров с шаблонами,

Там есть прекомпилированный формат исходников, из которого можно читать ровно столько, сколько надо. Clang внутри — это совсем не то, что ты думаешь :) Пруфов не проси.

В общем, те, кто хочет и знает как, те используют. Кто не знает как, продолжают думать, что это невозможно.

В общем, не пытайтесь меня убедить,

Я не пытаюсь. Я тебя просто информирую. Смотри мое предложение выше. JIT в LLVM, действительно, не профилирующий, «из коробки». Но возможность профилирования там есть.

Но возможность профилирования там есть.

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

На профики делал непосредственно Кондор. Она там шла официальной второй операционкой. По доработкам: ну они реализовали драйвера для страниц памяти, видео, работы с диском. Само ядро и функционал - стандартные.

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

Ага, ясно, спасибо. Выходит, достаточно было напилить драйвера, и никакой другой адаптации не надо. О чём мне уже здесь пытались сказать и раньше. :)

Я же сказал, что там есть «построение всего AST» — прекомпилированный в бинарный AST формат исходников.

Прекомпайлед хедеров не достаточно. Кто будет строить АСТ интерпретируемого сейчас юнита, и делать оптимизации по нему, если интерпретатор читает его построчно?

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

Нужны для чего? Ещё раз повторяю, что интерпретатору оттуда, на каждом отдельном шаге, может быть нужно совсем мало. А вот если вы статические оптимизации по всему АСТ делаете, то вам «непосредственно нужно» оттуда, как бы, всё целиком.

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

Т.е., да, внутренние представления Сlang не создавались специально под инкрементный JIT и, поэтому, проиграют специализированным под это дело языкам. Что вполне нормально. Но и JVM JIT тоже выполняет много всяких трансформаций кода в процессе работы.

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

Т.е., да, внутренние представления Сlang не создавались специально под инкрементный JIT

Да это опять какая-то подмена понятий, ведь проблема во всём том, что вы назвали, только одна: интерпретатор. При чём тут джит или силанг? У вас, в любом случае, интерпретатор «упускает» оптимизации AST-уровня.

Но и JVM JIT тоже выполняет много всяких трансформаций кода в процессе работы.

Там уже байт-код АОТ-оптимизирован. Оптимизации AST-уровня там попросту не нужны. Я не понимаю, почему вы до сих пор сравниваете это с каким-то сурс-левел интерпретатором - бросайте. :)

Важно то, что JIT для С++ есть

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

У вас, в любом случае, интерпретатор «упускает» оптимизации AST-уровня.

Что заставляет тебя так утверждать? Ты знаешь, как работает Clang и как делаются эти самые оптимизации AST-уровня?

Что заставляет тебя так утверждать?

Тот факт, что интерпретатор не строит AST всего юнита трансляции, а исполняет его «построчно». Этого не достаточно?

А что ты так упираешь на слово «интерпретатор»? Потому что пример назывался clang-interpreter?

А что ты так упираешь на слово «интерпретатор»? Потому что пример назывался clang-interpreter?

По тому, видимо, что я могу вводить туда плюсовый код руками, построчно? И он будет его исполнять по мере ввода? Интерпретаторы, обычно, так работают. Впрочем, трудно судить о том, как работает какой-то никому неведомый пример с гитхаба.

А, понятно. В Clang-interpreter нет REPL, который ты и имеешь в виду. REPL есть в Cling, но это сторонний проект. Там можно писать С++ интерактивно, выполнять выражения, и всё как в Питоне. На сколько оно эффективно? А на сколько надо? Это же REPL.

В неинтерактивном режиме «интерпретатор» работает на уровне transaltion unit. В момент окончания парсинга (построения AST), все оптимизации уже проведены. Такова семантика С++. Он «потоковый» за исключением нескольких частных случаев, когда порядок разрешения имен отличается от дефолтного.

Clang-interpreter работает на уровне translation unit. Это, по сути, такой же AOT, только динамический. Его можно переконфигурировать на использование инкрементного JIT, и тогда в промежуточный (и, далее, в машинный) код будут транслироваться только те фрагменты AST, которые выполняются.

Т.е. чтобы было понятней. Все оптимизации AST делаются в процессе парсинга TU, включая вывод всех типов и инстацирование всех шаблонов. Когда парсинг завершен, AST полностью готов. REPL в Cling, на сколько я знаю, просто делает новый TU на каждое новое выражение.

Если есть прекомпилированный AST-файл, то все AST-оптимизации в нем самом уже завершены. Если из этого файла берутся какие-то шаблоны, то они будут инстанцироваться в новом TU, и это займет время. Может быть, и большое, зависит от. JVM по этой самой причине открещивается от reified generics, как может.

Другое дело, что для того, чтобы всё это нормально работало, нужно иметь всё кодовое окружение прекомпилированным в AST-файлы. Т.е. это, как минимум, геморно. Если вообще заработает нормально и сразу. Этого нет «из коробки». Но суть в том, что внутри Clang куда более модульный и продвинутый, чем кажется снаружи.

Т.е. чтобы было понятней.

Да оно и так понятно, просто, блин, называть интерпретатором нечто даже без repl… Я понимаю, что, хоть горшком назови, но не настолько же. :)

нужно иметь всё кодовое окружение прекомпилированным в AST-файлы.

Вот в этом то и весь геморрой. Когда нету нужного TU - приходится всё окружение держать в каких-то мифических «AST-файлах» известного только вам формата. А когда TU есть - компилишь в байт-код, с оптимизацией и всеми остальными блэк-джеками. Соответственно, для чего это всё нужно - мне не особо понятно. Но, раз вам нужно, не буду мешать. :)

Тем более, что за вас уже всё сделали: https://github.com/bedatadriven/renjin/tree/master/tools/gcc-bridge

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

Для чего, если можно просто компилить в байткод?

Не буду мешать)

Рекомендую обратить взор на одну не очень популярную статью. От ее прочтения мир не перевернется, но даст пищу для размышления - https://www.ugolnik.info/unknown-sinclair/

Спасибо, почитаю. Прочитал первые абзацы и понял, что я в 90-е имел то, что не имели первые покупатели Спектрума - RGB видеовыход, который появился уже в 128КБ модели. С RGB - это был реально компьютер. Потом у меня уже появился Кворум, где был и SECAM выход. Но качество картинки было, мягко говоря, не очень. С текстом просто невозможно работать, даже при всей скудности графики Спектрума.

Там был YUV - это тоже самое, только другой системы. Есть желание - подключить было не сложно. Желания ни у кого не было, иначе были бы какие-то аксессуары для этого, они не сложны. Качество картинки после фирменного PAL кодера тоже было не очень, но дело в том, что графика стилизовалась под эти артефакты. Например, на лице у Рембо из-за артефактов PAL - зеленые полосы, на RGB там зелёного цвета вообще нет. Не смотри эмуляторы, они все сделаны без знания предметной области.