Header to include

Кто-нибудь знает проги, которые переводят заголовочные файлы в С/С++ на ассемблер (желательно MASM)?

 

SolidCode

MS предлагает h2inc.exe.

Afaik хорошего переводчика нет.

 

посмотри на http://www.magma.ca/~wjr

правда он больше заточен по GoAsm

 

Так может есть смысл сесть и сделать?

 

Такой (автоматический) конвертер всё равно будет бесполезен во многих случаях, кроме самых простых.

Слишком разный синтаксис у си и традиционного асма.

 

Я думал реализовывать это так.

Основное окно с двумя RichEdit-ами. В левом исходный вариант, в правом - преобразованный. Они должны работать "синхронно". Т.е. загружаем в левое окно исходный текст. Нажимаем "Конвертировать". Прога читает исходный построчно и анализирует. Анализ идёт на основе "словаря", в котором указываются исходный и получаемый результат. Перевод записывается в правый едит.

Если прога встречает что-то неизвестное, то останавливается на этой строчке, ожидая действий юзера (самостоятельной правки). Такой вариант можно и сохранить в текущий словарь. Поправив это, юзер ставит в исходном окне курсор после неизвестного сочетания и нажимает "Конвертировать" снова, чтобы продолжить. Частота остановок зависит от богатства "словаря". Для словаря надо разработать что-то типа формата файла, хотя в целом он должен быть простым текстовым файлом, который легко правится и подгоняется под соответствующие нужды. Таким образом прога становится просто конвертером и юзает те словари, какие есть. Её можно настроить в принципе для конвертации любого языка в любой другой. Она может идти с любым набором "словарей". Естественно, предполагается конвертирование заголовочных файлов и иже с ними. На конвертацию содержимого функций слишком много надо.

Я не претендую на абсолютно совершенный переводчик. Он лишь должен выполнять рутинную работу.

Интересно услышать предложения или замечания сообщества.

 

Построчный анализ текста не подходит - нужно как минимум склеивать строки заканчивающиеся знаком '\'

Но это мелочи.



Возьмём, для примера, Си макросы (#define)

#define foo bar

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

#define foo(X,Y) (X+Y)

?



А ещё есть сложные вложенные структуры, COM интерфейсы и т п. Здесь нужен синтаксческий разбор исходного Си текста. И не факт, что найдётся приемлимая для (конкретного) ассемблера выходная форма..



В общем, сложность подобной программы приближается к сложности полноценного компилятора, поэтому IMHO нужно этот компилятор и делать. Это будет компилятор ассемблера с Си-подобным синтаксисом

eax += ebx;

Тогда можно просто подключать хидеры и обрабатывать их непосредственно на этапе компиляции. Сам кодогенератор можно и не делать, а написать fron-end к fasm, как это сделал Randal Hyde.

 

Вообщем

#define foo(X,Y) (X+Y) превращается

в

macro foo X, Y

здесь сгенерированный код.

endm

Но как верно выразился S_T_A_S уж лучше сразу написать сишный компилятор. Просто парсингом строк дело никак не обойдется.

 

Проблема как раз получить

. в простейшем случае (X+Y) это элементарно, но есть и другие, например X->Y

Исли бы заголовочные файлы были бы не для Си, а для Паскаля, то было бы несколько проще =)

 

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

Примерчик



#define d1 500

#define d2 100

#define d3(X,Y) d1+d2 // подставим константы будет 600, что является константой



а например дефайн

#define short_n_simple(x, y, z)

while (x++) {

z->field1[++y] = 200;

z->field2 = NULL;

z++;

}



ассемблеру не нужно. Такие можно без опаски поскипать.

Мы их подставляем где нужно и убираем из хидера. Для препроцессирования GUID, UUID и всякой гуйни создать

отдельную анализирующую процедурку.

 

Поскольку

много, то и отдельных процедурок тоже будет не мало

 

Так как, я думаю, что под хидерами имеются ввиду инклюдники от Бормана и Мелкого, то проблемами в этих хидерах являются употребление языковых расширений, какие-то подсказки компилеру, линкеру. То есть там прагмы и т.д.

Их придется в любом случае обрабатывать.

Есть более легкий путь. Сувать инклюдник сначала препроцессору соответсвующего компилятора, а затем уже более чистый обрабатывать. Многие вопросы исчезнут сами.

 

MrHammer

Именно так и делает модуль для Перла (C::Scan, если не ошибаюсь)

 

MrHammer >

При программировании под виндос основной интерес представляют хидеры из PSDK, DDK, DXSDK, ... теоретичесик эти файлы должны пониматься _любым_ компилятором (практически DDK поддерживает только MSVC и немного Intel C++)



>

это ничего не даст!

предположим, в .h файле есть:

#define foo 0

а в asm файле

mov eax, bar+foo

как получить в asm файле 0 вместо foo? только обработав препроцессором _оба_ файла.

 

S_T_A_S писал:



это ничего не даст!

предположим, в .h файле есть:

#define foo 0

а в asm файле

mov eax, bar+foo

как получить в asm файле 0 вместо foo? только обработав препроцессором _оба_ файла.



)) Тогда это предложение отпадает само собой. Возвращаемся к тому, что треба создать препроцессор , учитывающий всякие извраты определенного компилятора.

В свете того, что винда бу Майкрософт и потому новые инклюдники от майкрософта в формате, понимемом его родным компилятором, то задача в том, чтобы учитывать всякие шпильки этого компилятора. Все-таки , чтоб создать новый аналог vc++ компилера не будет стоять наверное?

Создаем препроцессор и учитываем извраты M$ C++ компилера.

Астальное решится в ходе создания препроцессора.

Так как препроцессор не компилер, то сил потребуется не слишком то много.

 

1. заголовочные файлы из psdk (теоретически) совместимы с _любым_ С и/или С++ компилятором.



2. Си препроцессоров масса готовых. я сам написал такой как-то сдуру =)

сами по себе они ничем не помогут. нужен именно другой синтаксис "ассемблера".

 

P.S. Да , в придачу нужен синтаксический анализатор, но вместо них

Мона использовать специализированные программы

если самому писать в лом, тока они денег стоят.

Навскидку могу предложить поиграться с ССRIDER, Understand C++. Первый вообщем по идее должен понимать борландовские хидера от vcl. Но версия которую я использовал, не переваривала. Вторая прога тоже сойдет. В sourceforge поискать, может найдется бесплатный аналог.

 

STI Understand for C++ ??? чем он поможет? это же тулза для эээ... "понимания сорцов". или я что-то пропустил ? :-(

 

Да , в придачу нужен синтаксический анализатор, но вместо них

Мона использовать специализированные программы

если самому писать в лом, тока они денег стоят.





LLVM рулит