Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Знатоки, расскажите, pls, про gcc ;-) 14.09.04 13:07
Автор: HandleX <Александр М.> Статус: The Elderman
|
1) Почему "compiler collection"? Значит ли это, что gcc можно "научить" другому языку?
2) Это большой геморр обучить gcc компилить в какую-нибудь экзотику? Вообще во что-нить "марсианское", к примеру это совершенно новый процессор? ;-)
3) Это большой геморр приучить gcc к "другому" формату исполняемых файлов - не PE32, к примеру, а чего-нибудь абсолютно новому?
4) Итак, другой язык, другой формат объектного файла, другой набор машинных инструкций — gdb окажется в этом случае бесполезен, или он тоже "обучаем"?
Заранее большое спасибо за ответы.
|
|
Я бы посмотрел в сторону MontaVista Linux. Список... 15.09.04 11:26
Автор: catlion <catlion> Статус: Member
|
Я бы посмотрел в сторону MontaVista Linux. Список поддерживаемых процессоров тут: http://www.mvista.com/products/boards.html
У них есть бесплатная триалка. Процессор по выбору.
Используют gcc.
http://www.mvista.com/
|
|
Ответы 14.09.04 21:11
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> 1) Почему "compiler collection"? Значит ли это, что gcc
> можно "научить" другому языку?
Значит. У GCC типа-модульная структура, в которую входит так называемый компилятор переднего плана (frontend compiler), который преобразует код на некотором языке во "внутреннее представление" (по-моему, там C, но точно утверждать не буду), после чего за дело берется "компилятор заднего плана" и компилирует полученное в бинарный код под конкретную архитектуру. На сколько эта модульность реальна - сказать не берусь, но на данный момент GCC обучен C, C++ (по отдельности, кстати), Фортрану, Java, Аде и еще чему-то, по-моему.
> 2) Это большой геморр обучить gcc компилить в какую-нибудь
> экзотику? Вообще во что-нить "марсианское", к примеру это
> совершенно новый процессор? ;-)
Не слишком, насколько я понимаю. Проще, чем добавить новый язык. Но работы, конечно, достаточно. То есть по порядку сложности работа эквивалентна созданию компилятора с языка C под этот процессор.
> 3) Это большой геморр приучить gcc к "другому" формату
> исполняемых файлов - не PE32, к примеру, а чего-нибудь
> абсолютно новому?
Проще, чем предыдущий пункт, определенно. Фактически, речь не о компиляторе, а о линкере, поскольку именно он формирует готовые бинарники. Кстати, для нового языка линкер тоже, естественно, придется перелопатить.
> 4) Итак, другой язык, другой формат объектного файла,
> другой набор машинных инструкций — gdb окажется в этом
> случае бесполезен, или он тоже "обучаем"?
Ну в принципе можно заставить gdb понимать другие бинарные форматы, лишь бы отладочная информация была. Что касается языков, то если я не ошибаюсь, там довольно простая система абстракций файл-подпрограмма, так что с этим будет меньше всего мороки.
> Заранее большое спасибо за ответы.
Да пожалуйста, только ты скажи - зачем тебе нужна такая обобщенность? :) Может, проще свой компилятор написать? :)
|
| |
Уточнения (UPD) 15.09.04 11:04
Автор: leo <Леонид Юрьев> Статус: Elderman
Отредактировано 15.09.04 11:20 Количество правок: 1
|
> > 1) Почему "compiler collection"? Значит ли это, что
> gcc
> > можно "научить" другому языку?
> Значит. У GCC типа-модульная структура, в которую входит
> так называемый компилятор переднего плана (frontend
> compiler), который преобразует код на некотором языке во
> "внутреннее представление" (по-моему, там C, но точно
> утверждать не буду), после чего за дело берется "компилятор
Да, именно так. FrontEnd-ов довольно много, см. http://gcc.gnu.org/frontends.html
Сделать свой front-end IMHO проще чем "оседлать" новый процессор.
UPD: Забыл уточнить, frontend общается с backend не через "C", а генерит структуры tree-nod-ов и псевдо-код на RTL (register transfer language).
> > 2) Это большой геморр обучить gcc компилить в
> какую-нибудь
> > экзотику? Вообще во что-нить "марсианское", к примеру
> это
> > совершенно новый процессор? ;-)
> Не слишком, насколько я понимаю. Проще, чем добавить новый
> язык. Но работы, конечно, достаточно. То есть по порядку
IMHO не так просто. Машинно-независимый оптимизатор конечно есть в gcc, но большую роль играет кодо-генератор, который и придется делать. Добится состояния "лишь бы работало" гораздо проще чем сделать качественный и не-медленный генератор кода.
> > 3) Это большой геморр приучить gcc к "другому" формату
> > исполняемых файлов - не PE32, к примеру, а чего-нибудь
> > абсолютно новому?
> Проще, чем предыдущий пункт, определенно. Фактически, речь
> не о компиляторе, а о линкере, поскольку именно он
> формирует готовые бинарники. Кстати, для нового языка
> линкер тоже, естественно, придется перелопатить.
IMHO это самое простое, в 99.9% достаточно просто создать описание формата.
см. "GNU binutils".
|
| | |
Ух ты, это интересно... Читаю про RTL и не понимаю: зачем тогда придумали LLVM? Или это дальнейшее «движение вперёд»? 15.09.04 15:32
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| | | |
Это другой параллельный проект 15.09.04 16:43
Автор: leo <Леонид Юрьев> Статус: Elderman
|
LLVM "круче" gcc по трём позициям:
- идея "пожезненной" компиляции/оптимизации;
- межпроцедурная оптимизация во время линковки ("whole programm optimization");
- глобальная скалярная оптимизация с "наворотами";
|
| | | | |
Этих intermediate representation языков до фига 18.09.04 14:42
Автор: amirul <Serge> Статус: The Elderman
|
> LLVM "круче" gcc по трём позициям:
> - идея "пожезненной" компиляции/оптимизации;
> - межпроцедурная оптимизация во время линковки ("whole
> programm optimization");
> - глобальная скалярная оптимизация с "наворотами";
Монолитный компилятор может использовать для промежуточного представления обычное дерево (вернее направленный граф). Ну а если frontend отделен от backend-а, то в литературе чаще всего встречаются тройки, четверки (трехадресный и четырехадресный код), которые взаинооднозначно преобразуются в деревья и обратно. Ну а в реальности в качестве промежуточного представления используются ассемблеры некоторых виртуальных машин с неограниченным стеком и/или числом регистров (распределение регистров - часть кодогенерации). Мне встречался даже русский вариант промежуточного представления, называемый ЛиДер (линеаризованное дерево).
Тот же lcc использует Zephyr ASDL (http://www.cs.princeton.edu/zephyr/ASDL/).
Причем один из backend-ов генерирует код прямо в этот самый asdl. В gcc я не нашел target-а, компилирующего прямо в промежуточное представление.
|
| | | | | |
Кстати, если охота посмотреть RTL «вживую», то можно так: «gcc -dr code.c -o code », а потом смотреть файл «code.c.00.rtl». 24.09.04 18:50
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
