Программирование *

..it is true that asking regexes to parse arbitrary HTML is like asking Paris Hilton to write an operating system..

Последние версии языка Nemerle включают в состав библиотеку для разбора языков, грамматика которых принадлежит классу PEG.

Что такое PEG?

В отличии от других инструментов для создания парсеров, PEG описывает не грамматику, а стратегию её разбора, но фактически описание стратегии разора является описанием грамматики. Для парсера описанного с помощью PEG существует алгоритм (packrat), разбирающий любой текст, удовлетворяющий грамматике из этого класса, за линейное время от длинны текста.

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

Перевод третьей лекции из курса «Структура интерпретация компьютерных программ».

Это самый известный курс по программированию за последние 25 лет; с 1980г читается в MIT, а с недавних пор что-то подобное читается и в Беркли.

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

Мне бы очень хотелось, чтобы программирование у нас в стране преподавалось таким вот образом.

Приятного просмотра!

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

Под катом описана реализация этой идеи на JavaFX.

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

Далее в посте:

1. Оптимизация «в глазок»
2. Стандартные функции
3. Вывод в ELF
4. Как это работает?
5. Что получилось?

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

Далее в посте:

1. Выбор кода
2. Загрузчик
3. Изменения в п-коде
4. Генерация
5. Что получилось?

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

В качестве эксперимента выкладываю перевод первой из 20 лекций. Если это получит должный отклик, буду переводить дальше.

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

Далее в посте:

1. Починка бага
2. Чистка копирований
3. Что получилось?
4. Сворачивание констант
5. Реализация

В этой статье рассмотрим работу с тайловой графикой, прерываниями, сенсорным экраном и клавиатурой. На основе этого напишем всем с детства известную игру — «пятнашка».
Для начала поподробнее разберём работу с видеоконтроллером DS.

Инициализация видеоконтроллера

Практически все видеорежимы используют «многослойную» структуру организации вывода на экран, то есть одновременно мы можем отображать до 4-х планов (background). _{Не знаю хорошенько какой термин лучше использовать, пусть будет «план» — «задний план».}

Всего имеется 6 типов задних планов:

• framebuffer — Самый простой тип заднего плана. Каждое слово (16бит) в видеопамяти отображается в виде пикселя на экране. (Использовался в прошлом примере);
• 3D — Картинка на экране формируется OpenGL-подобными командами;
• text — Текстовый задний план (он же тайловый) разделён на блоки 8х8 пикселей, в каждом из которых отображается один из тайлов;
• rotation — Тайловый план с возможнотью вращения и масштабирования;
• extended rotation — Тоже что и фреймбуфер, но ещё позволяет отображать глубину цвета 8 бит на пиксель, а также поддерживает скроллинг, масштабирование и вращение, кроме того может использовать альфа-бит;
• large bitmap — Большие 512х1024 или 1024х512 изображения с 8 битами на пиксель.

В статье рассматриваются основы разработки программного обеспечения для Nintendo DS под Linux. Впрочем все используемые инструменты кроссплатформенные и не должно быть больших отличий для других ОС.

Для начала разберёмся, что же вообще из себя представляет эта игровая консоль. Вот, что нам говорит википедия:
* Процессор: ARM946E-S — 67 Мгц, сопроцессор ARM7TDMI — 33 МГц
* Память: 4 МБ, 656 КБ видео памяти, 512КБ памяти для текстур
* Экран: два отдельных ЖК-дисплея, диагональ 77 мм (3 дюйма), разрешение 256х192 пикселей, до 260 тысяч цветов. Расстояние между экранами — примерно 21 мм, что эквивалентно 92 «скрытым» строкам.
* Видеосистема: Поддержка 2D и 3D (T&L, преобразование координат текстур, маппинг текстур, альфа-смешивание, сглаживание, цел-шейдинг и Z-буферизация), теоретически позволяет отрисовывать 120 000 полигонов в сек (однако, имеет ограничение на отрисовку 6144 вершин или 2048 треугольников за один кадр).
* Звук: Стерео, 16-канальный ADPCM/PCM
* Накопители: 1 слот для собственных катриджей Nintendo DS, 2 слот для катриджей Nintendo Gameboy Advance
* Связь: IEEE 802.11 (Wi-Fi), для соединения используется собственный формат Nintendo. Радиус локальной сети от 10 до 30 метров в зависимости от условий.
* Управление: сенсорный экран, встроенный микрофон для голосовой идентификации, A/B/X/Y кнопки, D-Pad, шифты L/R, кнопки Start и Select
* Время работы: 6-10 часов
* Вес: 275 грамм
* Размеры: 148,7 × 84,7 × 28,9 мм

В серии статей от tyomitch «Компиляция» (тут, тут, тут, тут, тут и здесь) было рассмотрено построение транслятора игрушечного языка jsk, описанного в 4 части.
В качестве back-end для этого транслятора tyomitch предложил реализацию байт-кода и интерпретатор этого байт-кода.

На мой взгляд, более разумным подходом было бы использование существующих решений для backend, например llvm, и следуя принципу «Критика без конкретных предложений — критиканство», я предлагаю вариант реализации этого маленького языка jsk с llvm.

Что это даст для jsk? Настоящую компиляцию, то есть результатом будет исполняемый файл, который не зависит ни от каких runtime, возможность серьезной оптимизации, профилирования кода и автоматически получим документацию по back-end (что облегчит сопровождение).

Приветствую хабраюзеров, в этой статье пойдет речь о внутреннем устройстве компилятора LLVM. О том, что LLVM вообще такое, можно прочитать здесь или на llvm.org. Как известно, LLVM (условно) состоит из трех частей — байткода, стратегии компиляции и окружения aka LLVM infrastructure. Я рассмотрю последнее.

Содержание:

• Сборка LLVM
• Привязка к Eclipse
• Архитектура окружения
• LLVM API
• Оптимизация Hello, World!

File names are infinite in length, where infinity is set to 255 characters.
--Peter Collinson: The Unix File System

Итак, у нас есть программа на п-коде, и в её распоряжении неограниченное количество регистров (т.е. 255). Число регистров у реального процессора куда меньше (предположим, четыре). Что будем делать?

Далее в посте:

1. Разбор п-кода
2. Время жизни
3. Реализация
4. Простые оптимизации
5. Расщепление версий
6. Работа с памятью
7. Что получилось?

Первый этап — разбор синтаксиса нашего джей-скрипа — пройден; подбираемся к генерации кода.

Начнём с генерации п-кода (промежуточного переносимого псевдокода) — нечто вроде «абстрактного машинного языка». Его выбирают так, чтобы

• его было легко генерировать;
• его было легко обрабатывать.

Обработка п-кода — это, как правило, его переработка в исполнимый машинно-зависимый код. Тем не менее, можно ограничиться лишь генерацией п-кода, и объявить его готовой скомпилированной программой. Запуск такой программы будет, по сути, интерпретацией п-кода. У этого подхода всё больше и больше сторонников; так что и мы для начала ограничимся компиляцией в п-код.

Далее в посте:

1. Выбор кода
2. Компиляция
3. Выполнение
4. Backpatching

До сих пор занимались восходящим синтаксическим разбором. Какие ещё есть варианты?
Отложим бизона в сторону, и вернёмся к теории.

Далее в посте:

1. Идея
2. Воплощение
3. Холивар
4. Бэктрекинг

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

Чтобы неполноценность нашего языка была понятна уже из названия, назовём его JSkrip.

Далее в посте

1. Синтаксис
2. Грамматика
3. Парсер
4. Синтаксическое дерево
5. Pretty-printing

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

Далее в посте:

1. Компиляция грамматики
2. Двухступенчатый парсер
3. Что у него внутри?
4. Конфликты в грамматике
5. Как это работает?

В предыдущем посте было много кода и, по некоторым мнениям, недостаточно объяснений. Будем чередовать: в этот раз будет много теории, а до практики почти не дойдёт.

Далее в посте:

1. Магазинный автомат
2. Формальные грамматики
3. LR-парсинг

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

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

Далее в посте:

1. С какой стати писать компиляторы?
2. Общий план
3. Анализ текста
4. Практический пример
5. Как это работает?

На конференции OSCON (19-23 июля, Портленд) в этом году решили организовать дополнительную секцию Emerging Languages Camp, посвящённую языкам программирования нового поколения. Организатор — Алекс Пейн, известный по своей работе в компании Twitter.

Новые языки появляются постоянно и в бесчисленном количестве, потому что в программировании всё время возникают новые задачи, с которыми старые языки справляются плохо. Алекс Пейн говорит, что главная фундаментальная проблема сейчас — параллелизм. Он добавляет к этому ясность выражений (expressability) и удобство сопровождения (maintainability).

Начиная разработчиком на тогда еще сверх продвинутом IDE от компании Borland, bc++ 3.11, работающая в операционной системе DOS, в которой тогда единственное, чего не хватало — так это поддержки dos4gw (который вышел, если мне не изменяет память, парой годами позже), я любил эту IDE и мне казалось, что на ней можно сделать все что угодно. Была куча драйверов, которые писались энтузиастами, меняющие шрифты консоли, кодировку, была целая система работы с памятью… Прорывом были отгружаемые динамически библиотеки на диск, созданные чтобы вмесить все в память. Сегменты (ну, современные программисты, что такое сегменты оперативной памяти, и откуда 640К?), нижняя память, верхняя память… 640 килобайт… Люди придумывали все новые задачи компьютерам, а гении своего дела эти компьютеры придумывали. И ведь на самом-то деле это не так давно было… Это было почти вчера.