Header to include

S_T_A_S

чем он поможет? это же тулза для эээ... "понимания сорцов".

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

 

При чём здесь дизассемблер, декомпилятор?

Мы говорим о "понимании" сишных хидеров ассемблером.

 

S_T_A_S





Это будет компилятор ассемблера с Си-подобным синтаксисом

eax += ebx;



Меня несколько взволновали эти слова. Как ты сам сказал, имеется ввиду "понимание" сишных хидеров ассемблером. Так

зачем компилировать хидер, там же тока интерфейс ( по крайней мере для ассемблера). Имплементацию интерфейса оставим в покое( разные инлайны и т.п. и т.д.). Ассемблеру они не понадобятся. А если все таки нужно будет , пользователь может добавить их и сам вручную.

 

Не нужно путать разные вещи: "не понядобятся" и "ассемблер не может использовать информацию из заголовочных файлов" (не существует формата, понятного ассемблером, в который она может быть преобразована)



Существует 2 пути:



* выкидывать 80% информации из хидеров, поскольку нет формы, в которую моожно преобразовать эту инфу.

для этого нужно реализовать отдельный парсер хидеров, который оставшиеся 20% помещает в .inc файлы.

потом пользователь _вручную_ должен исправить / добавить всё то, что не смог сделать парсер для _каждого_ заголовочного файла.



* использовать не совместимые с ассемблером 80% инфы.

для этого нужно изменить сам ассемблер. парсер хидеров реализовать как его часть (препроцессор)



Если гора не идёт к Магомеду, то Мегомед идёт к горе. что тут не понятного?



ЗЫ: в заголовочных файлах нет имплементации.

 

Взяли библиотеку STL и что видим в инклюдниках? Реализация

функций, которые по идее должны быть в .cpp(.c, .cc).



"ассемблер не может использовать информацию из заголовочных файлов" (не существует формата, понятного ассемблером, в который она может быть преобразована)



Получается, что на ассемблере невозможно высказать высокоуровневую мысль.

 

Для чего в ассемблере структуры?

Дай, что ли для ясности примерчик геморроя из сишных хидеров. А com -интерфейсы, гуиды и т.п. легко можно

представить на асме в виде структур.

 

При чём тут STL и реализация?



Предположим, есть либа: .lib + .h (.hpp)

как это использовать с ассемблером?

Конвертить заголовки + править их вручную? И так для каждой либы :-(

я приводил раньше. В реальных хидерах есть куда сложнее.

GUID - это примитив.

Условный препроцессинг, макросы-функции и т.д. и т.п. - это тоже примитив, но как с этим быть?



Я достаточно хидеров ручками переконвертил, что бы говорить о малой полезности автоматического конвертера :-(

 

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

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

А проверка того , является ли символьное имя( дефайн) константой-числом, тривиальная. Конечно есть проблемка, када один дефайн является дефайном другого. Тогда сначала подставляем в дефайн более ранний, и далее по плану.

Пример для ясности:

#define magic 1

#define black_magic magic



код



if ( cast == black_magic) {}

то есть в асме реально нам понадобится символьное имя числа 1 black_magic и magic. Magic сразу определяется как

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

P.S. Чтобы абламать мой базар, представьте примерчик какой-нить, который точно будет непростым для примитивного разбора.

Предположим, есть либа: .lib + .h (.hpp)

У тасма32 в принципе достаточно продвинутый конвертер, тока я так и не сумел им сконвертировать с++-классы. Ху

его знает, в чем проблема.

 

понятие .c/.cpp и .h это условные понятия. ПРИНЯТО в .h описывать интерфейс а в .c/.cpp реализацию, но это не обязательно. Возьмите тот-же WTL - примеры по дефолту ВООБЩЕ не используют .cpp файлы, кроме stdafx и трех строк с main.

 

MrHammer >

Вот видишь, ты тоже согласен с тем, что нужно использовать Си-препроцессор. Раз так, то что мешает использовать его при каждой компиляции исходника? То, что он не интегрирован в ассемблер?



>

Ну дык не знает он ничего про такие вещи. Потому и говорю - нужно добавлять фичи.

Для Спектрума и то уже сделали ассемблер, который понимает namespace...



Вот кстати, WTL - хороший пример - что там будет делать конвертер Header to include?





infern0 >

Потому и написАл

, а не .h, подразумевая, что это только объявления. Конвертировать имплементацию в asm (заренее) практически не реально..

 

Я еще знаю, что такое ATL, но про WTL только смутная ассоциация. В любом случае посмотрю. Конечно ассемблер для х86 нужно модернизировать, я сам за слияние с hll - языками.

 

Посмотрел я на инклюдники WTL. В нем все имплементация методов классов находится в обявъвлении класса. То есть чтобы разобрать такой хидер нужен синтаксический разбор

-> "як, конский як" -> анализатор синтаксиса.

 

все обычные define я заменяю на equ, более продвинутые на textequ catstr или struct хотя с макро я еще не разбиралься, еще не возникало необходимости.



foo equ 0

bar equ еще что-то



mov eax,bar+foo работает м не нужно оба файла обрабатывать





А что в си делает "X->Y" ? "offset X.Y" разве не пойдет ?





Какой смысл переделывать всe си файлы, зачем тогда асм вообще



Вообще вручную напечатать намного быстрее чем придумывать переводчик. Вы ж не каждый день делаете новый инк

 

А что в си делает "X->Y" ? "offset X.Y" разве не пойдет ?



x->y - обращение по указателю, которое разрешается во время выполнения, а x.y нередко можно посчитать уже во время компиляции, если адрес X уже известен. К X прибавляем смещение X и в ассемблерном коде будет непосредственно адрес члена структуры. Ну а такой код

x->y.z во время компиляции вычисляется тока частично ( y.z), остальное уже в рантайме.

 

Вообще вручную напечатать намного быстрее чем придумывать переводчик. Вы ж не каждый день делаете новый инк



Я готов поспорить, что создание переводчика более простое решение. Для этого нужны flex и byacc(bison).



что легче, написать для яка правило типа



unit

: /* empty */

| unit define_statement

;



define_statement

: '#' tkDEFINE tkID expression {

if ($4 == T_INTEGER) {

// ...

}

else {

// ...

}

}

| '#' tkDEFINE tkID '(' arg_list ')' mcr_foo_body

;



expression

// тут стандартное

;

arg_list

: tkID

| arg_list ',' tkID

;



macro_foo_body

: anything '\\'

| macro_foo_bdoy anything '\n'

и т.д.



...или корпеть вручную над хидерами?

 

нуу, легче уж



perl -n -e "chomp; print /^#define (\w+)(\s+)([\w\.]+)(.*)/ ? qq/$1 $2= $3 ;$4\n/ : qq/; $_\n/" GL.H >gl.inc

 

И во flex используются регулярные выражения. Я уж даже не уверен, что обратили внимание на этот момент: " а нафига в ассемблере дефайны , значение которых целым не является? А для отделения плевел от зерен анализ треба, что выполнить специализированными инструментами гораздо легче.

IceStudent

Насчет простоты согласен.