Вижу на SVN иной способ передачи данных из среды (HiAsm) в CodeGen...
Контр-соображений против универсальности не возникает
Возникают на предмет эффективности такого способа.
Понятно, что для CodeGen эффективность не самый больной вопрос, но все-таки...
Ведь в мыслях же продолжает сидеть необходимый способ обмена данными для dll-к и плагов

Чем большим количеством типов мы захотим обмениваться, тем больше и больше будет разбухать интерфейс, что не есть хорошо
Вот припоминаю тип TValue, используемый в CallDLL....
Почему не что-то похожее
Для его окончательной "универсализации" добавить к нему еще одно поле Length, и можно будет даже различить real от extended
Кстати тип получится совпадающий с виндячим COPYDATASTRUCT, т.е., почти стандарт. А может и не почти, если поле Length установить ПЕРЕД полем Value, а на поле DType отвести 4 байта (именно столько ведь и отводится, если нет атрибута packed)
И строки появится возможность передавать не только как pchar, а любые паскалевские (доработать ф-ю LoadResData из share, чтобы она возвращала не pchar, а string - не представляется проблематичным, полная аналогия с LoadResStream).
В случае data_stream в Value содержался бы PStream.Memory, а в Length - PStream.size.
Для картинок - полная аналогия с файлами (но уж не PBitmap).

Вот и обнаружил желание получать таки в CodeGen непосредственно данные, несмотря на наличие интерфейсных методов, помещающих данные в ресурс "не глядя".
Это существенно с позиций универсальности.
Пример: FASM, скажем, должен иметь право решать САМОСТОЯТЕЛЬНО, помещать данные в ресурс, или непосредственно в сегмент данных (второе-то, запросто может оказаться рациональнее).
Да и ресурс FASM может сформировать самостоятельно. Собственно, только такой вариант сегодня и просматривается, если надо подключить XP-ресурс, скажем.

---

Почему я склоняюсь к некому интерфейсному типу...
Потому что проблемный вопрос интерфейса у нас не один - для CodeGen.
Связь плага со средой - то же интерфейсный вопрос. Этот вопрос очень похож (логические корни-то те же) на совместимость приложения и dll-ки, сделанных разными компиляторами.
На заре создания проекта hiDLL, мы видели, сделанная на FPC dll-ка не очень подключается к приложению на Дельфи.
Но сказали - ну и фиг с ним, с FPC. Фактически...
Ну заработает через какое-то время FASM, и этот вопрос (к примеру, плаги на fasm-е) станет значительно более интересным.
И хотелось бы отметить, что вопрос DLL-к не очень замыкается внутри соответствующих элементов.
Во-первых, плаг - это тоже DLL-ка, и нелогично было бы делать два разных механизма, для очень похожих конструкций
Во-вторых, есть массивы и матрицы. И тут либо не разрешать этот тип для интерфейса, либо аргументы и возвращаемые значения ф-й (указатели не которые составляют структуры TMatrix и TXArray) должны быть нашего предполагаемого интерфейсного типа (а не TData)... И это будет касаться элементов уже не имеющих отношения к DLL-кам

А далее рассуждаю так:
1) Пусть существуют ДВЕ интерфейсные проблемы, и их можно решать независимо
2) Решение второй - это путь интерфейсного типа
3) Решение любой проблемы - это встряска нашей системы, сопровождаемая несовместимостью с предыдущим
4) Поэтому лучше трясти один раз, а не два...
5) А если мы решили ВТОРУЮ интерфейсную проблему, то ПОЧЕМУ бы нам не решить ТОЧНО так же и первую.

Мне кажется, это было бы рациональнее
Хотя думать о всем сразу посложнее...
Но это только если сравнивать с решением одной. А если всех
Все одно решать все придется...