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

Это сообщение отредактировал(а) ТарасАтавин - 16.9.2013, 13:59

Могу посоветовать книжку по ассемблеру. Думаю, что больше ничего тут не нужно - все и так очевидно. Сложней парсить исходный код...

Книжка по ассемблеру у меня есть. А толку? Что то я ни разу при разработке интерпретаторов в неё не заглядывал, а тут надо скрестить интерпретатор с компилятором: написать компилятор, который бы компилировал программу на языке высокого уровня в промежуточный кодированный язык, максимально сохраняющий строй исходного, заменив лишь инфиксные и постфиксные операторы префиксными кодами, но сохраняя все идентификаторы, кроме идентификаторов констант, а именованный константы всё таки заменять при компиляции явными, причём, полученный код должен быть объединён в одном исполняем файле со своим интерпретатором, при этом операции требуется закодировать адресами соответствующих процедур интерпретатора, а не словами. При этом, в том же файле ещё должна располагаться копия исходного текста и при дебаге этого безобразия надо отображать именно то место в исходнике, которое соответствует коду, который будет исполняться следующим. Вот я и прошу порекомендовать литературу по теории трансляторов. Да и по ассемблеру есть вопрос, не рассмотренный в книге. Выполнена инструкция CALL, управление передано в процедуру. Как бы вытянуть в регистры данные по адресу возврата, а потом увеличить адрес возврата на размер операндов? PUSHить операнды не пойдёт, надо реализовать соглашение о вызовах, по которому операнды процедуры располагаются сразу за операндом операции CALL (адресом вызова).

Это сообщение отредактировал(а) ТарасАтавин - 18.9.2013, 19:53

http://forum.vingrad.ru/forum/ASM-forum.html ?

наименьшая из проблем

не лучшее решение работы с отладочной информацией

книгу дракона осилил?

Возможно.

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

Добавлено через 1 минуту и 52 секунды
простейшая реализация "генерации кода" может выглядеть примерно так:
допустим, реализуется интерпретатор целочисленных арифметических выражений с бинарными операциями + - 
инструкции (адреса функций, реализующих указанные операции) заносятся в массив, для операндов используется стек
вот игрушечный пример http://ideone.com/jcECGV

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

необязательно

Интересно, как ты вообще разместишь в исполняемом файле только внешние адреса? Импортировать то функции можно, но загрузка dll вызывается из уже запущенной программы и она должна сама куда то присвоить указатели на dll-ные функции.

причем тут dll. и исполняемый (в смысле - exe) файл.

При том, что это программный код. Так вот, программа должна иметь исполняемую форму, а генерируемый код не может быть исходником. Ну и что это тогда, кроме исполняемого файла? Мало того, если ты не компилишь, а пишешь сразу в коде, то смысл транслировать будет только мнемоники. А числовой код здесь при чём? Там ведь код операции call по определению в нативе, а не на языке ассемблера, который всё таки иначе называется. А если прога вообще не транслируется, значит пишется сразу исполняемая версия. К расширению exe это как раз не относится, на спектруме исполняемым был байт-код бейсика, а тип исполняемых файлов имел расширение B (латинская бэ большая), а не exe. Исполняемый может быть и elf, и чем угодно ещё. Но чем бы он ни был, откуда ты вообще возьмёшь адреса до того, как сама же программа вызовет LoadLibrary, или её аналог в ином API и присвоишь адреса указателям? Даже если интерпретатор находится в ПЗУ, получаешь дикую зависимость от версии ПЗУ. Ладно ещё в байт-коде можно сохранять совместимость, договорившись новые коды добавлять только в определённый диапазон. Или договорившись о том, что строго определённый коды будут зарезервированными префиксами. Или в начале файла разместив информацию о версии и договорившись, что все виртуальные машины твоего байт-кода должны или таскать за собой свои старые версии, или предлагать их загрузку и установку, если интерпретатор всё таки новей кода. Но что ты будешь делать, если устаревший адрес указан операндом операции call? А если какая то часть начинает исполняться с самого файла, а какая то с другого, то это программа и динамически связываемая библиотека, как бы её тип ни назывался и какой бы формат она не имела. Я умудрялся на спектруме B-файлы вместо динамических библиотек юзать, но целиком собрать всю прогу только динамически нельзя, что то должно быть приложением, а что то может быть библиотекой. Или не быть. Но ни как не наоборот. Не может исполняться библиотека без приложения, хоть ты текст бейсика объяви исполняемым форматом, хоть шифротекст рапиры.

многабукф, нечитал
есть пример - язык MDL (диалект C, средство разработки MicroStation). Основатели утверждают, что он компилируется в шитый код (видимо так и было в первых версиях). Но получается не exe а промежуточное платформонезависимое представление, интерпретируемое ядром MicroStation.
шитый код - способ представления, а уж как исполнить дело десятое.

Во-первых есть шитый код, а есть близкие к нему коды, в том числе байт-код и Ваша же ссылка на первые версии может быть понята так, что действительно шитым он был в первой версии, а промежуточное представление получается в более новых. Во-вторых если уж процессор pentium интерпретирует CISC-опкоды системой команд, сам имея RISC-ядро, но вполне справляется с исполнением интерпретаторов, в свою очередь интерпретирующих исходный текст бейсика, то уже получаем два уровня интерпретации, а код может быть шитым в том смысле, что содержит call-инструкции уже виртуальной машины и с адресами процедур в её коде. Если ты шитый код в нативе z-80 запустишь на эмуляторе, который сам написан в x86 и установлен на машине на базе pentium, код от этого шитым быть не перестанет, но исполняемым он будет для другой машины. Кто сказал, что она должна быть физической? Реализовать то шитый код можно с адресами из ПЗУ. Но не нужно. А если программа вообще не способна исполняться, то она не имеет смыла.

Это сообщение отредактировал(а) ТарасАтавин - 7.10.2013, 19:03

Или как на спектруме приложение в одном коде, а загрузчик к нему в другом? Фиг его знает, может это тоже шитый.

Добавлено @ 19:08
На спектруме водится даже оптимизируюзий компилятор бейсика в p-код, а викепедия утверждает, что p-код есть "натив" виртуальной паскаль-машины. 

Это сообщение отредактировал(а) ТарасАтавин - 7.10.2013, 19:09