
Список задач составлен, форматирование произведено, осталось выполнить TODO и можно дальше ехать.
p.s. Ну и намучился я со структурой TCodeGenTools

Ответов: 1841
Рейтинг: 369
|
|||
Ну вот, первый этап выполнен
![]() Список задач составлен, форматирование произведено, осталось выполнить TODO и можно дальше ехать. p.s. Ну и намучился я со структурой TCodeGenTools ![]() |
|||
карма: 1 |
| ||
Голосовали: | LastLeader |
Ответов: 1841
Рейтинг: 369
|
|||
Потихонечку уже начинает получаться
![]() Например, схема: "HiAsm_AltBuildElementsdelphiExampleOpenGLHiAsm3D.sha" hiasm3d.7z Тут мы выводим значения переменных элементов, с учётом вложенности контейнеров. Или, схема: "HiAsm_AltBuildElementsCNETExamplegraphicsArcanoid.sha" arcanoid.7z Т.е. имеем поддержку контейнеров и полиморфных контейнеров любой (относительно ![]() ![]() Формат сохранения будет скорее всего в json (текстовый и бинарный формат). |
|||
карма: 1 |
| ||
файлы: 2 | arcanoid.7z [2KB] [357], hiasm3d.7z [1.8KB] [378] | ||
Голосовали: | 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 |
|