Предлагаю прийти к консенсусу. :) В те времена, о которых мы говорим, сложность ЯП не предполагала серьёзной работы по проектированию и не выигрывала от неё. Сегодня ситуация иная и, действительно, есть ЯП, которые показывают высокий класс инженерной школы. Ява — действительно яркий пример. Только будем откровенны. Я тоже считаю, что Ява — это высокий класс, но миру в среднем похрен и вполне наколенный Питон очень выраженно Яву вытесняет.
Насчёт предпросмотра k символов Вы, конечно, правы, но при рекурсивном спуске эти к символов лежат в потоке управления, который привёл нас сюда, а _здесь_ выбор всегда определяется одним следующим символом. И ad hock языки именно так и растут — добавим в этот свитч ещё один токен.
Не сочтите меня противником инженерии и проектирования. Я — сторонник. Только я ещё и реалист. Я, собственно это Вам изначально и написал — формальная модель возникает не до, а после, и инструментом проектирования ЯП не является. Как правило.
Мало того — это ещё и хорошо, потому что голова у программиста тоже не резиновая, и сложный синтаксис — это беда.
1. Проектирование.
1а: посмотрите на perl, php, lua, c (!!) и даже на python и расскажите мне про проектирование. Реально используемые ЯП созданы ad hock. На коленях. Си вырос из макроассемблера. Итеративно. Собственно, всё реальное растёт из говна итеративно.
1б: Проектирование бывает. Но не является ни обязательным, ни критически важным. Синтаксис языка вообще мало отражает и сложность его, и степень его спроектированности. Сложный синтаксис не нужен ни для чего. Ни для программиста, ни для автора ЯП.
2. Я уже писал. На входе яка — БНФ, но это ВООБЩЕ не значит, что автор файла mylang.y хоть что-то понимает в теории формальных грамматик. Как правило — не понимает. Для описания ЯП это не нужно.
3. Про Фортран я Вам рассказал в своём комментарии. С учётом этого факта Ваша формулировка «надеюсь знаете» меня удивляет.
4. «А как убедиться, что язык получился контекстно-свободным?» — Вы теоретик, или писали компиляторы? Во-первых, всем пофигу, получился язык контекстно свободным, или нет. Ну — вообще пофигу. (Си контекстно зависим, и всем плевать.) Во-вторых при рекурсивном спуске у вас или достаточно информации для принятия решения о продолжении разбора, или недостаточно. И это просто очевидно в каждой точке реального кода парсера. Ну и да, контекстно свободным язык получается если принятие решения опирается только на следующий токен. А зависимым — если ещё и в таблицу символов заглядывать.
Я извиняю, но написал я в самом начале простую вещь: БНФ и танцы с грамматиками — это наука. А написание компиляторов — это ремесло. Оно отлично делается без науки. Хуже того, наука не сильно помогает его делать. А зачем она нужна — это отдельный вопрос.
1. Я могу высказаться более однозначно. За исключением монстров типа А68 написание компилятора не требует никаких теоретических знаний. Более того, никто никогда не проектирует грамматику языка, которую потом реализуют. Любой нормальный человек пишет компилятор, а потом записывает в виде грамматики то, что получилось, если вдруг очень хочется выглядеть круто. Я чуток утрирую. Не сильно. Иногда компилятор пишут сразу на базе yacc/bison/другой генератор, и тогда исходник имеет вид, близкий к БНФ. Но не надо обманывать себя — это не значит, что автор знаком с теорией.
2. В 60-м были Фортран, Лисп и Алгол. А, ещё Кобол. Из этих четверых на какую-то грамматику может претендовать только Алгол. Остальные примитивны донельзя и разбираются парой switch-ей. Фортран ВООБЩЕ невыразим в БНФ. В Фортране тех времён DOI=1,3,1 парсилось как DO I = ..., то есть даже разделения на лексер и парсер не было. Нельзя для него передрать готовую грамматику. А Лисп и Кобол парсить — да, это, конечно, без БНФ ну никак не прорваться. Одних скобок — не сосчитать, сколько.
3. Я верно понимаю, что clang передрал у gcc готовую грамматику? Или когда буржуй реализует ЯП, то это «реализует», а если русский реализует, то это «передрал»? И мы что обсуждаем — научные работы по тематике формальных грамматик, или реализацию программистами СССР популярных ЯП?
И про Wang. С Искрами-226 я сам работал в то время. Это не украденый Ванг, это машина, которая была спроектирована полностью в СССР, и которая была программно совместима с Wang-ом. Заказчиком был Госплан, они купили пару тысяч вангов, а потом наши посмотрели на систему команд и сделали машину на советской элементной базе и под нашу периферию. Вот насчёт софта — не знаю, может его и тиснули. Машину спроектировали сами. Кстати, отличная была машина, даром, что на бейсике. Говорят, впрочем, что на неё Юникс в Киеве портанули.
Это эмоции. А по факту представительство IBM в СССР было открыто, ЕМНИП, в 1972 году и находилось в историческом центре Москвы в очень приличном здании. И я полагаю, что формальные ограничения на экспорт этой технологии, которые, судя по всему, на них налагало правительство США, были как-то обойдены. Я очень сомневаюсь, что IBM стал бы открывать офис в стране, которая его бысстыдно обворовывает.
Мысль довольно очевидная, такой тикет у Фантома даже стоит в планах.
Тут бы надо разделять две сущности. Генерацию объекта по факту потребности в нём и memory mapping. Первое вполне возможно без второго, вообще говоря. Запрашиваем глиф, если его нет в кеше рендеринга, то рисуем и выдаём. При исчезновении всех ссылающихся на глиф объектов он остаётся только в кеше. Кеш прореживаем по LRU.
Мне отображение в память больше виделось как инструмент для доступа к сетевым ресурсам.
Ну вот то, что я написал выше, кажется, полностью подходит.
keyCode — или код функциональной клавиши (тот же X11 code), или latin1 char. Используется именно как управляющая клавиша в контексте команды и для восстановления кода в эмуляторах. 1:1 соответствует клавише. Не модифицируется раскладкой.
ttyChar — только printable, с трансляцией раскладки. Если нет printable кода, то ноль. По нулю можно переключаться на командные символы из keyCode в строках ввода, где нет командной модальности.
modifiers — все биты альтов и контролов, keyUp и прочие meta.
Насчёт одной очереди — если отрисовка встала, то мы всё равно не увидим эффекта от ввода. Хотя, конечно, сделать две отдельные очереди не так и сложно. Меня эта мысль тоже посещала.
Гарантии — нет. Программы разрабатываются исходя из предположения, что пейджинг включен. Хотя, конечно, по факту на сегодня типовой сценарий — памяти заведомо больше, чем рабочее множество суммы приложений.
1. Системный вызов номер 7. Запуск приложения. Я не нашёл никого, кто бы чётко понимал, как работает распаковщик. В итоге удалось сделать запуск только распакованных приложений.
То есть, в теории даже есть сишный код распаковщика и структура заголовка упакованного образа приложения, но сделанная по имеющемуся описанию реализация не работает.
Если вдруг Вы в курсе, как оно должно быть устроено, то, может быть, подскажете? Код вот тут:
2. Сравнение JIT/AOT — тема сложная и небанальная.
— Есть много критериев. Объём кода. Объём данных. Скорость работы. Объём данных — если на типовом сценарии вылезаем из кеша — может убить скорость.
— Есть много сценариев. Монотонные операции и работа на сильно разных данных. Во втором случае JIT может давать катастрофический выигрыш за счёт перекомпиляции на ходу с учётом анализа фактического графа исполнения и направлений переходов.
— Есть разный код. Ява способна свернуть константы на пачку функций внутрь цепочки вызовов и оптимизировать то, что статический линкер никак не может.
И т.п.
Ну и тупые тесты показывают, что jvm vs gcc даёт вполне сравнимые результаты. Где-то в пользу си, где-то в пользу Явы.
По сути Вы совершенно правы, так и надо. Более того, я проделал серию экспериментов с софтверным GL-ем в качестве базиса для оконной системы.
Но — на всё рук не хватает, да и акселерированные драйвера современных видеокарт — это ад и израиль, несколько подходов к снаряду вида «что бы такого втянуть целым кусочком» пока кроме глубокой задумчивости результатов не дали. :)
Так что пока я тактически отступил к 2D.
Присоединяйтесь, сделайте это, будет действительно здорово. Я уже представляю себе шелл с трёхмеркой и окнами, которые сложены в стопочку в углу экрана. :)
Да чёрт с ней, она дешевеет с каждым годом, память-то. Ну и требования персистентности диктуют. Есть гарантия, что рестарт приложения выдаст юзеру предыдущую картинку его окна мгновенно.
Никакие игры никогда не работают с данными, которые отсутствуют в оперативной памяти. Любая оперативная память приложения виртуальна. И нет гарантии, что она подкреплена физической памятью. Ни в какой ОС.
Изначально сжатые данные приложением разжимаются при начале работы.
Имитировать функции чтения из обычной ОС (ФС?) не приходится. Фантом легко хранит содержимое скомпрессированного объекта просто в строке и из неё же можно распарсить финальный объект.
Не подробные. Когда начинаешь писать вылезает миллион вопросов, и ответов нет. Навскидку первый: как распаковать бинарник приложения. Имеющаяся документация на этот счёт ошибочна.
(Искреннее спасибо за подробный разбор. Всё очень по делу.)
Из VNC не приезжают IBM scan codes, приезжают как раз иксовые коды.
Сам по себе IBM scan code — штука мерзкая, а ближе к принтскрину и вообще сумасшедшая, не хочется его применять как опорный.
Может быть, обойтись троицей?
— Нетранслированный x11 code или ascii char без локализации
— char транслированный по полной — если нажат ctrl, то 00-1F, если локальный кеймап, то кириллица/японица, что там — в UTF32. Короче, tty char
— модификаторы
Кажется, эта схема закрывает всё и хорошо ложится на VNC и X11.
Насчёт предпросмотра k символов Вы, конечно, правы, но при рекурсивном спуске эти к символов лежат в потоке управления, который привёл нас сюда, а _здесь_ выбор всегда определяется одним следующим символом. И ad hock языки именно так и растут — добавим в этот свитч ещё один токен.
Не сочтите меня противником инженерии и проектирования. Я — сторонник. Только я ещё и реалист. Я, собственно это Вам изначально и написал — формальная модель возникает не до, а после, и инструментом проектирования ЯП не является. Как правило.
Мало того — это ещё и хорошо, потому что голова у программиста тоже не резиновая, и сложный синтаксис — это беда.
С уважением.
1а: посмотрите на perl, php, lua, c (!!) и даже на python и расскажите мне про проектирование. Реально используемые ЯП созданы ad hock. На коленях. Си вырос из макроассемблера. Итеративно. Собственно, всё реальное растёт из говна итеративно.
1б: Проектирование бывает. Но не является ни обязательным, ни критически важным. Синтаксис языка вообще мало отражает и сложность его, и степень его спроектированности. Сложный синтаксис не нужен ни для чего. Ни для программиста, ни для автора ЯП.
2. Я уже писал. На входе яка — БНФ, но это ВООБЩЕ не значит, что автор файла mylang.y хоть что-то понимает в теории формальных грамматик. Как правило — не понимает. Для описания ЯП это не нужно.
3. Про Фортран я Вам рассказал в своём комментарии. С учётом этого факта Ваша формулировка «надеюсь знаете» меня удивляет.
4. «А как убедиться, что язык получился контекстно-свободным?» — Вы теоретик, или писали компиляторы? Во-первых, всем пофигу, получился язык контекстно свободным, или нет. Ну — вообще пофигу. (Си контекстно зависим, и всем плевать.) Во-вторых при рекурсивном спуске у вас или достаточно информации для принятия решения о продолжении разбора, или недостаточно. И это просто очевидно в каждой точке реального кода парсера. Ну и да, контекстно свободным язык получается если принятие решения опирается только на следующий токен. А зависимым — если ещё и в таблицу символов заглядывать.
Я извиняю, но написал я в самом начале простую вещь: БНФ и танцы с грамматиками — это наука. А написание компиляторов — это ремесло. Оно отлично делается без науки. Хуже того, наука не сильно помогает его делать. А зачем она нужна — это отдельный вопрос.
2. В 60-м были Фортран, Лисп и Алгол. А, ещё Кобол. Из этих четверых на какую-то грамматику может претендовать только Алгол. Остальные примитивны донельзя и разбираются парой switch-ей. Фортран ВООБЩЕ невыразим в БНФ. В Фортране тех времён DOI=1,3,1 парсилось как DO I = ..., то есть даже разделения на лексер и парсер не было. Нельзя для него передрать готовую грамматику. А Лисп и Кобол парсить — да, это, конечно, без БНФ ну никак не прорваться. Одних скобок — не сосчитать, сколько.
3. Я верно понимаю, что clang передрал у gcc готовую грамматику? Или когда буржуй реализует ЯП, то это «реализует», а если русский реализует, то это «передрал»? И мы что обсуждаем — научные работы по тематике формальных грамматик, или реализацию программистами СССР популярных ЯП?
www.wang2200.org/iskra-226.html
Тут бы надо разделять две сущности. Генерацию объекта по факту потребности в нём и memory mapping. Первое вполне возможно без второго, вообще говоря. Запрашиваем глиф, если его нет в кеше рендеринга, то рисуем и выдаём. При исчезновении всех ссылающихся на глиф объектов он остаётся только в кеше. Кеш прореживаем по LRU.
Мне отображение в память больше виделось как инструмент для доступа к сетевым ресурсам.
keyCode — или код функциональной клавиши (тот же X11 code), или latin1 char. Используется именно как управляющая клавиша в контексте команды и для восстановления кода в эмуляторах. 1:1 соответствует клавише. Не модифицируется раскладкой.
ttyChar — только printable, с трансляцией раскладки. Если нет printable кода, то ноль. По нулю можно переключаться на командные символы из keyCode в строках ввода, где нет командной модальности.
modifiers — все биты альтов и контролов, keyUp и прочие meta.
А технически то запереть странички и в Фантоме можно, тут разницы нет.
То есть, в теории даже есть сишный код распаковщика и структура заголовка упакованного образа приложения, но сделанная по имеющемуся описанию реализация не работает.
Если вдруг Вы в курсе, как оно должно быть устроено, то, может быть, подскажете? Код вот тут:
github.com/dzavalishin/phantomuserland/blob/master/oldtree/kernel/phantom/elf.c#L131
2. Сравнение JIT/AOT — тема сложная и небанальная.
— Есть много критериев. Объём кода. Объём данных. Скорость работы. Объём данных — если на типовом сценарии вылезаем из кеша — может убить скорость.
— Есть много сценариев. Монотонные операции и работа на сильно разных данных. Во втором случае JIT может давать катастрофический выигрыш за счёт перекомпиляции на ходу с учётом анализа фактического графа исполнения и направлений переходов.
— Есть разный код. Ява способна свернуть константы на пачку функций внутрь цепочки вызовов и оптимизировать то, что статический линкер никак не может.
И т.п.
Ну и тупые тесты показывают, что jvm vs gcc даёт вполне сравнимые результаты. Где-то в пользу си, где-то в пользу Явы.
www.stefankrause.net/wp/?p=4
www.codenet.ru/webmast/java/javavscpp.php
Ну и, собственно, явский JIT не проигрывает прямой компиляции. Да и, в целом, никаких причин для того, чтобы ему проигрывать не видно.
Другое дело, что и до джита Фантому ещё надо дожить. А вот, кстати, АОТ сделать проще.
Но — на всё рук не хватает, да и акселерированные драйвера современных видеокарт — это ад и израиль, несколько подходов к снаряду вида «что бы такого втянуть целым кусочком» пока кроме глубокой задумчивости результатов не дали. :)
Так что пока я тактически отступил к 2D.
Присоединяйтесь, сделайте это, будет действительно здорово. Я уже представляю себе шелл с трёхмеркой и окнами, которые сложены в стопочку в углу экрана. :)
Изначально сжатые данные приложением разжимаются при начале работы.
Имитировать функции чтения из обычной ОС (ФС?) не приходится. Фантом легко хранит содержимое скомпрессированного объекта просто в строке и из неё же можно распарсить финальный объект.
Вот тут есть пример программы для Фантома: phantomdox.readthedocs.io/en/latest/#example-of-phantom-program
Обратите внимание на строки
bmp = new .internal.bitmap();
bmp.loadFromString(getBackgroundImage());
По сути они сводятся к
bmp.loadFromString(import "../resources/backgrounds/weather_window.ppm");
Конструкция import возвращает строковую константу, инициализированную содержимым файла в момент компиляции.
Эта строка будет содержать в данном случае картинку в файловом формате.
loadFromString парсит и конвертирует в финальный битмап, который и живёт в персистентной переменной.
VM будет закрыт JIT-ом.
Из VNC не приезжают IBM scan codes, приезжают как раз иксовые коды.
Сам по себе IBM scan code — штука мерзкая, а ближе к принтскрину и вообще сумасшедшая, не хочется его применять как опорный.
Может быть, обойтись троицей?
— Нетранслированный x11 code или ascii char без локализации
— char транслированный по полной — если нажат ctrl, то 00-1F, если локальный кеймап, то кириллица/японица, что там — в UTF32. Короче, tty char
— модификаторы
Кажется, эта схема закрывает всё и хорошо ложится на VNC и X11.