Совершать невозможное и раздавать пинки здравому смыслу — в этом и состоит жизнь членов Гуррен-Дана! (C) Камина
Эта статья вступает в техническую полемику со статьей 2015 года за авторством AtakuaЧитать полностью »
Рубрика «interpreter»
Глобально оптимальный, восьмой и наиболее быстрый вид интерпретаторов байткода
2024-11-06 в 10:51, admin, рубрики: AOT, binary translation, branch prediction, interpreter, jit, simulation, tail call optimization, tail recursion, threaded, байт-кодПростой интерпретатор Lisp на Umka
2020-09-26 в 18:22, admin, рубрики: compiler, interpreter, интерпретатор, компилятор, Компиляторы, Программирование, функциональное программированиеРазработка моего статически типизированного скриптового языка Umka вошла в ту стадию, когда потребовалась проверка языковых возможностей на более сложных примерах, чем скрипты в пару десятков строк. Для этого я решил реализовать на своём языке интерпретатор Lisp. На это меня вдохновил педагогический эксперимент Роба Пайка, одного из создателей языка Go. Недавно Пайк опубликовал маленький интерпретатор Lisp на Go. Особенно впечатлило замечание Пайка, что описание интерпретатора заключено на одной странице 13 древнего Читать полностью »
Umka. Жизнь статической типизации в скриптовом языке
2020-06-21 в 10:18, admin, рубрики: C, embedded languages, Go, interpreter, Lua, scripting language, static typing, virtual machine, виртуальная машина, встраиваемые языки, интерпретатор, Компиляторы, Программирование, скриптовый язык, статическая типизация
В своё время посты на Хабре и Reddit о статически типизированном скриптовом языке Umka вызвали весьма активную дискуссию.
Прошедшие полтора месяца позволили мне избавиться от некоторых заблуждений, развить язык и дать чуть более вразумительные ответы на вопросы публики. Как и следовало ожидать, наиболее серьёзное испытание выпало на долю самой концепции статической типизации. Она осталась в основе языка, но потребовала компромиссов — в частности, для корректной сборки мусора.
Появились первые замеры быстродействия интерпретатора в сравнении с Wren и Python — их результаты внушают оптимизм. Наконец, родился более реалистичный пример использования Umka по его основному назначению, т. е. как встраиваемого языка.
Читать полностью »
Low-level Brainfuck
2018-11-03 в 19:12, admin, рубрики: assembly, Brainfuck, interpreter, Pascal, tasm, ПрограммированиеBuilding a Brainfuck translator in TurboAssembler.
To begin with, we will write an interpreter in a high-level language, for example, in Pascal.
Let's write a program that outputs a character whose ascii-code corresponds to the number of +
Therefore, we only need the bf-commands + and .
var
data_mem: array[1..10] of integer; // data array
command_mem: string; // command array
i: integer; // index of command array
j: integer; // index of data array
begin
j:=1;
readln(command_mem);
for i:=1 to length(command_mem) do begin // in the cycle we process the string
if (command_mem[i]='+') then data_mem[j]:= data_mem[j]+1;
if (command_mem[i]='.') then write(chr(data_mem[j]));
end;
end.
bf-code +++++++++++++++++++++++++++++++++. will issue !
(the ascii-code of the symbol ! is 33).
The efficiency of the program can be checked in online ide ideone.com.
Читать полностью »
[Археология Java] Контекстно-зависимый инлайнинг трейсов в Java
2017-05-20 в 22:21, admin, рубрики: compiler, interpreter, java, vmКоротко о статье
Инлайнинг методов – одна из наиболее важных оптимизаций в JIT-компиляторах (которые благодаря ей называются «основанными на методах» или «блочными»). Эта оптимизация расширяет область компиляции, позволяя оптимизировать несколько методов как единое целое, что повышает производительность приложений. Однако, если использовать инлайнинг методов слишком часто, время компиляции станет излишне большим, и будет сгенерировано слишком много машинного кода. И вот это скажется на производительность уже негативно.
Трассирующие JIT-компиляторы собирают не всё подряд, а только часто исполняемые пути, так называемые трейсы. С помощью этого можно получить более быструю компиляцию, уменьшить количество сгенерированного машинного кода, и улучшить его качество. В предыдущих наших работах, мы реализовали инфраструктуру для записи трейсов и трассирующий Java-компилятор, модифицируя код Java HotSpot VM. Основываясь на этой работе, мы посчитали, какой эффект инлайнинг трейсов оказывает на производительность и количество генерируемого кода.
Читать полностью »
Возвращаясь к Неразмеченным Конечным Интерпретаторам с Dotty
2017-04-06 в 15:22, admin, рубрики: finally-tagless, interpreter, scala, переводНеразмеченные Конечные Интепретаторы (Tagless Final interpreters — прим. пер.) — это альтернативный подход традиционным Алгебраическим Типам Данных (и обобщённым ADT), основанный на реализации паттерна "интерпретатор". Этот текст представляет "неразмеченный конечный" подход в Scala, и демонстрирует каким образом Dotty с его недавно добавленными типами неявных функций делает этот подход ещё более привлекательным. Все примеры кода — это прямое переложение их Haskell версий, представленных в Typed Tagless Final Interpreters: Lecture Notes (раздел 2).
Паттерн "интерпретатор" в последнее время привлекает всё больше внимания в сообществе Scala. Множество усилий было затрачено на борьбу с наиболее ярким недостатком решений, основанных на ADT/GADT: расширяемость. Для начала можно взглянуть на typeclass Inject из cats как на реализацию идей Data Type à la Carte. Библиотека Freek предоставляет средства для комбинирования более двух алгебр, используя украшения с задействованием аппарата операций на уровне типов. Решение, предложенное в работе Freer Monads, More Extensible Effects также ставит акцент на расширяемости, и вдохновлено набором небольших Scala-библиотек, таких как eff, emm и paperdoll. Неразмеченные конечные интерпретаторы подходят в некотором смысле с противоположной стороны, используя типы классов в своём непосредственном основании вместо более традиционных ADT/GADT. Они также поставляются с большим превосходством в расширяемости "из коробки" без каких-то явных опасностей.
Ассемблер для задач симуляции. Часть 1: гостевой ассемблер
2015-04-06 в 6:03, admin, рубрики: binary translation, decoder, ia32, interpreter, simulation, virtualization, x86, Блог компании Intel, Программирование, системное программирование, метки: assemblerInstructions, registers, and assembler directives are always in UPPER CASE to remind you that assembly programming is a fraught endeavor
golang.org/doc/asm
На Хабре да и в Интернете в целом есть довольно много информации про использование языков ассемблера для всевозможных архитектур. Пролистав доступные материалы, я обнаружил, что чаще всего освещаемые в них области использования ассемблера и родственных технологий следующие:
- Встраиваемые (embedded) системы.
- Декомпиляция, обратная разработка (reverse engineering), компьютерная безопасность.
- Высокопроизводительные вычисления (HPC) и оптимизация программ.
И конечно же, в каждой из этих областей существуют специфические требования, а значит свои понятия об инструментах и «свой» ассемблер. Эмбедщики смотрят в код через редактор и дебаггер, реверс-инженеры видят его в декомпиляторах вроде IDA и radare2 и отладчиках ICE, а HPC-спецы — через профилировщики, такие как Intel® VTune™ Amplifier, xperf или perf.
И захотелось мне рассказать об ещё одной области программирования, в которой ассемблеры частые спутники. А именно — об их роли при разработке программных моделей вычислительных систем, в простонародье именуемых симуляторами.
Читать полностью »
Типы данных наносят ответный удар
2014-11-04 в 19:27, admin, рубрики: cpython, interpreter, python, python3, Блог компании Mail.Ru Group, ПрограммированиеЭто вторая часть моих размышлений на тему «Python, каким бы я хотел его видеть», и в ней мы более подробно рассмотрим систему типов. Для этого нам снова придётся углубиться в особенности реализации языка Python и его интерпретатора CPython.
Если вы программист на языке Python, для вас типы данных всегда оставались за кадром. Они где-то там существуют сами по себе и как-то там взаимодействуют друг с другом, но чаще всего вы задумываетесь об их существовании только когда возникает ошибка. И тогда исключение говорит вам, что какой-то из типов данных ведёт себя не так, как вы от него ожидали.
Python всегда гордился своей реализацией системы типов. Я помню, как много лет назад читал документацию, в которой был целый раздел о преимуществах утиной типизации. Давайте начистоту: да, в практических целях утиная типизация — хорошее решение. Если вы ничем не ограничены и нет нужды бороться с типами данных по причине их отсутствия, вы можете создавать очень красивые API. Особенно легко на Python получается решать повседневные задачи.
Практически все API, которые я реализовывал на Python, не работали в других языках программирования. Даже такая простая вещь, как обычный кликабельный интерфейс просто не работает в других языках, и основная причина в том, что вам приходится беспрестанно бороться с типами данных.
Не так давно поднимался вопрос добавления статической типизации в Python, и я искренне надеюсь, что лёд, наконец, тронулся. Постараюсь объяснить, почему я против явной типизации, и почему надеюсь, что Python никогда не пойдёт по этому пути.
Python, каким бы я хотел его видеть
2014-08-28 в 8:49, admin, рубрики: cpython, interpreter, python, python3, Блог компании Mail.Ru Group, ПрограммированиеВсем известно, что мне не нравится третья версия Python и то, в каком направлении развивается этот язык программирования. За последние несколько месяцев я получил много писем с вопросами о моём видении развития Python и решил поделиться своими мыслями с сообществом, чтобы, по возможности, дать пищу для размышлений будущим разработчикам языка :)
Можно сказать совершенно точно: Python не является идеальным языком программирования. На мой взгляд, основные проблемы вытекают из особенностей интерпретатора и мало связаны с самим языком, однако все эти нюансы интерпретатора постепенно становятся частью самого языка и поэтому они так важны.
Я хочу начать наш разговор с одной странности интерпретатора (слоты) и закончить его самой большой ошибкой архитектуры языка. По сути, эта серия постов является исследованием решений, заложенных в архитектуре интерпретатора, и их влияния как на интерпретатор, так и на сам язык. Я считаю, что с точки зрения общего дизайна языка такие статьи будут выглядеть гораздо интереснее, чем просто высказывание мыслей по улучшению Python.
Читать полностью »
Программная симуляция микропроцессора. Коробка передач
2013-12-09 в 6:54, admin, рубрики: interpreter, simulation, virtualization, Блог компании Intel, виртуализация, интерпретатор, Процессоры, симуляция, метки: interpreter, simulation, virtualization, виртуализация, интерпретатор, симуляция 
В этой статье я хочу рассказать о том, как создатели симуляторов добиваются максимальной производительности моделей процессоров, при этом не жертвуя гибкостью и расширяемостью полного решения. Если кратко, то решение состоит в сосуществовании нескольких движков, наилучшие качества которых используются на различных этапах работы модели.
Содержимое данной заметки будет основываться на моём опыте разработки функциональных симуляторов, а также на публикациях и технических статьях, описывающих различные симуляторы и виртуальные машины: Wind River Simics, VMWare, Qemu, Bochs и другим. Слово «функциональный» в контексте данной статьи обозначает то, что точность моделей ограничена уровнем набора команд (instruction set architecture, ISA).
Читать полностью »