Реально ли (теоретически) описать грамматику для ваших анализаторов, чтобы получился интерпретатор С++? Хотя бы без темплейтов.
Вполне, только само собой не LR(0)-анализатор используется, да и большую часть кода генерит «компилятор компиляторов» — yacc.
Если интересно — ftp.iecc.com/pub/file/c++grammar/
Какая пропасть лежит между «деревом исходного кода» и объектным файлом для x86 формата Elf/WinPE? То есть если вообще отказаться от любой оптимизации, насколько сложно из дерева построить объектный файл?
После синтаксического анализа идёт этап семантического (контекстного), который работает не с конкретной синтаксической единицей, а со всем кодом (например, проверка типизации, если объявили int a, а через 10 строк записываем туда float). После этого чаще всего происходит оптимизация (возможно перед оптимизацией перевод во внутренний промежуточный язык, в качестве которого можно использовать и описанный в статье). Далее идёт кодогенерация, это процесс получения байт-кода, понятного машине (виртуальной, а-ля Java, или реальной — x86, arm, ...). А уже потом приходит время «форматтера» — модуля, который собирает получившийся байт-код в один из форматов, ожидаемый на выходе (объектные чаще всего, но можно генерировать сразу в исполняемый, как делает например компилятор fasm). Такие дела. Для простейшего языка, наподобие трехадресного, кодогенерация проста, а сложность форматтера зависит от сложности выходного формата, что логично.
Есть ли такие планы на будущее?
Именно ELF/PE не особо интересует в том плане, что существует довольно большое число открытых исходников и компиляторов, и форматтеров. Достаточно умеючи выпилить их из сорцов и использовать в своих проектах.
P.P.S. Этот вопрос несколько не по теме. Насколько реально создать линкёр, который мог бы связывать объектные файлы разных форматов, а именно Elf и WinPE?
Иногда возможно, если присутствует необходимая информация, например таблица релокации.
Чтоб точно ответить на вопрос нужно внимательно изучить и сравнить оба этих формата.
там не нужно собирать, github предоставляет так же возможность публикации статик-страниц.
Но как-то не стабильно работает эта функция, сразу не всегда открывает.
опасаясь того, что вы в ответ подпортите им карму? )
как раз для того чтобы оценка и была более-менее объективна и не показывается такое.
а то будет детский сад, штаны на лямках — «он меня минуснул, дай-ка я ему отомщу!»
Мне показались они слишком жадными :)
Решил зарегать ИП, нужно 2 счета — рублёвый расчетный и валютный расчетный.
На каждый нужно по usb-токену за 1700 рублей + абонентка 500 рублей за счет + 500 рублей в месяц за карты заргенные на физ лицо.
1500 рублей в месяц мне жалко отдавать. Хотя сумма и маленькая, но наблюдая тарифы в других банках душит жаба связываться с альфобанком.
А Интернет-банкинг у них лучший в России, да.
на вкус и цвет, можно и в hiew, конечно, ковырять гадость :)
однако многие знакомые занятые в сфере RE (в том числе и «зверюшек») пользуются hexrays и графами. Говорят, что так быстрее и понятнее разбираться в коде.
PS: Сам я тоже не пользуюсь этими фичами, но полезность их совсем не отрицаю :)
у вас именно 5.5? :) Бесплатный апдейт.
Только замечу что у вас должен быть саппорт активен (с покупкой. ЕМНИП, на год даётся).
И всё же вероятность что версия == 5.5 и куплена крайне мала.
А насчет ИМХО не соглашусь, изменений ОЧЕНЬ много, самые глобальные — graph view, appcall, hexrays, arm, изменения в gui.
на кряклабе бы не одобрили такую статью, ибо это чуть ли не основы.
немножко пикантности придаёт то, что это линуксовый крякми, но всё равно на узкопрофильном ресурсе мало кому нужна такая статья.
Пару лет назад пробовал программировать с использованием видеокарты.
Бутылочным горлышком был обмен данными между памятью карты и оперативкой.
Тесла в этом плане мне нравится куда больше.
Хотя конечно зависит от задач, не всегда требуется обработка больших массивов данных.
PS: не верю в экзофлоп через 8 лет, технологический рывок в производстве процессоров ожидается только лет через 10, кроме того необходимо будет полносью переписывать весь софт.
Вполне, только само собой не LR(0)-анализатор используется, да и большую часть кода генерит «компилятор компиляторов» — yacc.
Если интересно — ftp.iecc.com/pub/file/c++grammar/
После синтаксического анализа идёт этап семантического (контекстного), который работает не с конкретной синтаксической единицей, а со всем кодом (например, проверка типизации, если объявили int a, а через 10 строк записываем туда float). После этого чаще всего происходит оптимизация (возможно перед оптимизацией перевод во внутренний промежуточный язык, в качестве которого можно использовать и описанный в статье). Далее идёт кодогенерация, это процесс получения байт-кода, понятного машине (виртуальной, а-ля Java, или реальной — x86, arm, ...). А уже потом приходит время «форматтера» — модуля, который собирает получившийся байт-код в один из форматов, ожидаемый на выходе (объектные чаще всего, но можно генерировать сразу в исполняемый, как делает например компилятор fasm). Такие дела. Для простейшего языка, наподобие трехадресного, кодогенерация проста, а сложность форматтера зависит от сложности выходного формата, что логично.
Именно ELF/PE не особо интересует в том плане, что существует довольно большое число открытых исходников и компиляторов, и форматтеров. Достаточно умеючи выпилить их из сорцов и использовать в своих проектах.
Иногда возможно, если присутствует необходимая информация, например таблица релокации.
Чтоб точно ответить на вопрос нужно внимательно изучить и сравнить оба этих формата.
если бы их были десятки, то тогда можно было бы поискать лучший.
Но как-то не стабильно работает эта функция, сразу не всегда открывает.
имхо логика подразумевает radio.
если есть задачи для таких мощностей и финансовые ресурсы, то проблем нет никаких.
Практически единственный лимитирующий фактор — скорость инета.
как раз для того чтобы оценка и была более-менее объективна и не показывается такое.
а то будет детский сад, штаны на лямках — «он меня минуснул, дай-ка я ему отомщу!»
Решил зарегать ИП, нужно 2 счета — рублёвый расчетный и валютный расчетный.
На каждый нужно по usb-токену за 1700 рублей + абонентка 500 рублей за счет + 500 рублей в месяц за карты заргенные на физ лицо.
1500 рублей в месяц мне жалко отдавать. Хотя сумма и маленькая, но наблюдая тарифы в других банках душит жаба связываться с альфобанком.
А Интернет-банкинг у них лучший в России, да.
Однако, конечно, 2 байта держать там, гед можно обойтись чаще всего одним бывает накладно.
однако многие знакомые занятые в сфере RE (в том числе и «зверюшек») пользуются hexrays и графами. Говорят, что так быстрее и понятнее разбираться в коде.
PS: Сам я тоже не пользуюсь этими фичами, но полезность их совсем не отрицаю :)
Бесплатный апдейт.
Только замечу что у вас должен быть саппорт активен (с покупкой. ЕМНИП, на год даётся).
И всё же вероятность что версия == 5.5 и куплена крайне мала.
А насчет ИМХО не соглашусь, изменений ОЧЕНЬ много, самые глобальные — graph view, appcall, hexrays, arm, изменения в gui.
немножко пикантности придаёт то, что это линуксовый крякми, но всё равно на узкопрофильном ресурсе мало кому нужна такая статья.
вышеупомянутая мною шестая версия имеет интерфейс построенный на Qt.
пруф
Бутылочным горлышком был обмен данными между памятью карты и оперативкой.
Тесла в этом плане мне нравится куда больше.
Хотя конечно зависит от задач, не всегда требуется обработка больших массивов данных.
PS: не верю в экзофлоп через 8 лет, технологический рывок в производстве процессоров ожидается только лет через 10, кроме того необходимо будет полносью переписывать весь софт.