Ну вот, первый этап выполнен
Список задач составлен, форматирование произведено, осталось выполнить TODO и можно дальше ехать.
p.s. Ну и намучился я со структурой TCodeGenTools Каша ещё та...
Этот топик читают: Гость
Ответов: 1841
Рейтинг: 369
|
|||
карма: 1 |
| ||
Голосовали: | LastLeader |
Ответов: 1841
Рейтинг: 369
|
|||
Потихонечку уже начинает получаться
Например, схема: "HiAsm_AltBuildElementsdelphiExampleOpenGLHiAsm3D.sha" hiasm3d.7z Тут мы выводим значения переменных элементов, с учётом вложенности контейнеров. Или, схема: "HiAsm_AltBuildElementsCNETExamplegraphicsArcanoid.sha" arcanoid.7z Т.е. имеем поддержку контейнеров и полиморфных контейнеров любой (относительно ) вложенности Формат сохранения будет скорее всего в json (текстовый и бинарный формат). |
|||
карма: 1 |
| ||
файлы: 2 | arcanoid.7z [2KB] [337], hiasm3d.7z [1.8KB] [356] | ||
Голосовали: | LastLeader |
Главный модератор
Ответов: 2999
Рейтинг: 396
|
|||
CriDos писал(а): намучился я со структурой TCodeGenToolsCriDos, Удалось ли Вам «достучаться» до «дельфячего» кодогенератора из «плюсов»? Если да, то не поделитесь ли вашим кодом обращения к функциям кодогенератора? |
|||
карма: 6 |
|
Ответов: 1841
Рейтинг: 369
|
|||
Nic писал(а): «дельфячего» кодогенератора из «плюсов»?Ещё не пробовал стучать в него. Ибо, сначала нужно полностью воспроизвести механизм взаимодействия кодогенератора и среды в прокси-интерфейсе (частично реализовано), и только потом, подключать к прокси-интерфейсу кодогенераторы. Без этого промежуточного интерфейса, нет смысла работать напрямую с кодогенераторами, т.к. их функционал тесно завязан на коллбеках среды А само подключение кодогенераторов, не должно быть проблемой в теории ------------ Дoбавленo в 01.33: Если у Вас проблема именно в соглашениях вызовов, то вот небольшой пример (gcc_4.9.2, c++11) проверки поддержки версии среды кодогенератором, путём вызова функции CheckVersionProc delphi кодогенератора: http://pastebin.com/k0P2VMM0 |
|||
карма: 1 |
|
Главный модератор
Ответов: 2999
Рейтинг: 396
|
|||
CriDos писал(а): ...проблема именно в соглашениях вызовов...Установить проблему пока не удаётся. Рабочая гипотеза - неодинаковая передача параметров строковых данных через стек, требующая дополнительных «приседаний» как раз в callback'ax. |
|||
карма: 6 |
|
Ответов: 1841
Рейтинг: 369
|
|||
Ну, если имеется ввиду функция:
Дале, у нас передаётся ссылка (жесткий указатель) на структуру:
Точнее, нужно заранее в памяти держать всю необходимую кодогенератору информацию о схеме и предоставлять к ней доступ посредству этих вот методов. С получением аргументов данных в методах, тоже не должно быть проблем, т.к. все необходимые сложные типы данных, описаны Автором в плюсовом заголовке CGTShare.h (если Автор корректно их описал относительно дельфи реализации), иначе нужно смотреть в реализацию cgt. В крайнем случае, можно попробовать собрать кодогенератор с отладочной информацией, добавив к аргументам сборки параметры "-V -VN", и попробовать отлаживать всё это дело в gdb Если он понимает дельфячий формат отладочной инфы. ------------ Дoбавленo в 13.06: CriDos писал(а): extern "C" __declspec(dllimport) заместо FASTCALLХотя, нотацию extern "C" __declspec(dllimport) вообще можно опустить, т.к. соглашение по умолчанию используемое в плюсам соответствует cdecl. ------------ Дoбавленo в 13.18: Провёл небольшой эксперимент. В кодогенераторе добавил пару строк:
Далее, был переписан немного предыдущий пример на плюсах: http://pastebin.com/BvgJtK82 В результате, после запуска получаем несколько сообщений с выводом "123" и "333" и падение на строке:
Т.е. из этого следует, что параметры передаются корректно. С этого момента, проблемы могут возникать только из-за несоответствий в структурах данных. |
|||
карма: 1 |
|
Ответов: 316
Рейтинг: 21
|
|||
Nic, У нас есть постоянно весящий скайп чат, тематика - продвижение хиасма, есть желание подключиться?
Для обмена идеями. |
|||
карма: 1 |
|
Ответов: 1841
Рейтинг: 369
|
|||
Если что, на основе предыдущих наработок, открыл новый проект HiAsm_ProxyInterface: https://github.com/CriDos/HiAsm_ProxyInterface
В дальнейшем, возможно, будет объединён с проектом HiAsm_Interface. Библиотека является промежуточным звеном между средой и кодогенератором, которая транслирует все полученные данные из среды в кодогенератор, и наоборот. Очень удобная штука для изучения кодогенератора или отладки взаимодействия с оным. На данным момент, полностью работает загрузка, сборка и запуск схемы из среды (HiAsm 4) через промежуточную библиотеку. |
|||
карма: 1 |
|
Главный модератор
Ответов: 2999
Рейтинг: 396
|
|||
Библиотека является промежуточным звеном между средой и кодогенератором Попробую посмотреть. Может этого будет достаточно. ------------ Дoбавленo в 21.40: Nic писал(а): Попробую посмотретьС этими вызовами проблем, как мне кажется, нет. Проблемы в обработке вызовов (callback) из «дельфячего» кодогенератора. |
|||
карма: 6 |
|
Ответов: 1841
Рейтинг: 369
|
|||
Nic писал(а): С этими вызовами проблем, как мне кажется, нет. Проблемы в обработке вызовов (callback) из «дельфячего» кодогенератора.Сейчас как раз занимаюсь проксированием структуры TCodeGenTools со всеми его методами. Сегодня-завтра постараюсь закончить. Посмотрим что получится. ------------ Дoбавленo в 06.53: Ну вот, все 85 функций структуры TCodeGenTools - "проксированы" Вот что уже удаётся получить при загрузке, сборке и запуске пустой схемы, Windows пакета: Массив информации
Пришлось отказаться от использования структуры TCodeGenTools, т.к. она больше сбивает с толку, с её полями-указателями на функции, ещё и неудобно в неё тыкать указатели на свои функции Так что у меня все функции находятся в массиве указателей. Код как всегда тут: https://github.com/CriDos/HiAsm_ProxyInterface Позже добавлю больше информации для вывода. ------------ Дoбавленo в 14.43: Немного причесал код и добавил вывод информации об аргументах функций и их значениях на момент вызова. Обновлённый вывод: http://pastebin.com/vmh4uGq4 |
|||
карма: 1 |
| ||
Голосовали: | Nic |
Ответов: 2059
Рейтинг: 132
|
|||
CriDos,
Правильно я понимаю, что речь идёт о структуре, где вызовы "компонентов" через CALL, или указатели? [flood]На медне делал компонент - получилась туча точек. Разбил на шесть (тусовал функционал туда, сюда) и пришёл в ужас от того, что каждый компонент в HiAsm прописан отдельным кодом, а не как uses или функция. Понятно, что hiFunction и hiCallFunction - плохая замена овсу.[/flood] |
|||
карма: 6 |
|
Ответов: 1841
Рейтинг: 369
|
|||
flint2 писал(а): что речь идёт о структуре, где вызовы "компонентов" через CALL?Что ещё за вызовы "компонентов" через CALL? Имеются ввиду callback функции? Если Вы имеете ввиду структуру TCodeGenTools, то она больше похожа на массив, чем на структуру. Данные этой структуры организованы в памяти таким же образом, как и в обычном массиве (относительно GCC C/C++/delphi4), и имеют одинаковый тип данных, что делает возможным работать со структурой TCodeGenTools также, как и с обычным массивом. Ну а каждое поле этой структуры, является обычным адресом (указателем) на начало блока памяти в области HiAsm.exe, где и расположена функция. Далее, в C++ мы говорим компилятору, что у нас есть переменная-указатель, которая содержит адрес на вот такую функцию и описываем её сигнатуру, ну и вызываем её Через сами функции, мы не вызываем компоненты, лишь получаем из среды какую либо информацию об элементе или данных, которые он хранит/привязаны к нему и используем эту информацию для генерации кода. Как-то так. |
|||
карма: 1 |
| ||
Голосовали: | flint2 |
Ответов: 2059
Рейтинг: 132
|
|||
CriDos,
Спасибо, ПОНЯЛ. Ну а каждое поле этой структуры, является обычным адресом (указателем) на начало блока памяти в области HiAsm.exe ... Далее, в C++ мы говорим компилятору, что у нас есть переменная-указатель, которая содержит адрес на вот такую функцию и описываем её сигнатуру ...И про callback тоже. [flood] Что ещё за вызовы "компонентов" через CALL? Я имел ввиду, что вызов кода компонента происходит через ассемблерную команду CALL, что код компонента прописан только один раз, а не как сейчас. Т.е. если в схеме стоит 20 одинаковых компонентов, то и в *.exe присутствует код на все 20 компонент. Сейчас это похоже на JMP на всё новый и новый код (это образно). [/flood] Начал вникать, а то не всё прочитал. Понравилось! Сразу есть мысли, но надо подумать, как их правильно изложить. ...И прочитать всё с начала до конца! |
|||
карма: 6 |
|
Ответов: 1841
Рейтинг: 369
|
|||
flint2 писал(а): Я имел ввиду, что вызов кода компонента происходит через ассемблерную команду CALL, что код компонента прописан только один раз, а не как сейчас.
flint2 писал(а): код компонента прописан только один раз, а не как сейчас.Тут как такового, нет кода компонента. Есть среда с API (callback). Ты получаешь в своё распоряжение ID контейнера (основная схема) и массив функций для работы с этим контейнером, его объектами/свойствами/параметрами и т.д. Далее, ты с помощью этого API перебираешь объекты в этом контейнере (элементы), читая их параметры, передавая ID параметров в другие вспомогательные функции, получая информацию. Вот так вот кодогенератор и переребирает один за другим элементы/контейнеры/etc. И тут неважно Delphi, FTCG или RTCG кодогенератор, все они используют одинаковый принцип получения информации о схеме (разная последовательность и другие нюансы могут отличаться). Куда и сколько экземпляров кода элемента писать, уже решает кодогенератор. |
|||
карма: 1 |
|
Ответов: 2059
Рейтинг: 132
|
|||
CriDos,
Тут как такового, нет кода компонента. Это главное! Есть среда с API (callback). Куда и сколько экземпляров кода элемента писать, уже решает кодогенератор. Это я потом понял. Одно дело собрать информацию - пропарсить схему, а другое сгенерить код. ---------------------------------------------------------------------------------------------- Конечный код получается без мусора в виде незадействованного кода? Т.е. целевая компиляция? Т.е. если таскать за собой, предположим dll от QT, то получается избыточный код в виде незадействованных функций dll. Или большие uses библиотеки, из которых 80% функций не задействовано. Это как пример. Лирика: [flood]Я как то делал программку для выдирания нужных кусков кода из dll в виде ассемблерного кода. С метками, переменными и т.д.[/flood] |
|||
карма: 6 |
|