The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Представлен новый компактный компилятор 8cc, opennews (??), 01-Мрт-15, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


19. "Представлен новый компактный компилятор 8cc"  +/
Сообщение от CrazyAlex25 (ok), 01-Мрт-15, 22:28 
Так tcc вроде забросили, а значит не будет добавлен C11
Ответить | Правка | Наверх | Cообщить модератору

35. "Представлен новый компактный компилятор 8cc"  –1 +/
Сообщение от Аноним (-), 02-Мрт-15, 00:54 
> Так tcc вроде забросили, а значит не будет добавлен C11

Для мизерного наколенного компилера это не самая большая из проблем. Для начала там качество кодогенерации обычно таково что оно годится только как действующий макет "а я что-то тоже скомпилять могу!"

Ответить | Правка | Наверх | Cообщить модератору

42. "Представлен новый компактный компилятор 8cc"  +/
Сообщение от seyko2email (ok), 02-Мрт-15, 05:27 
Вообще-то пилят потихоньку. А как компилятор tcc фактически turbo cc. Ядро 2.4.26 (минимальная конфигурация) собирает за 30 секунд. И оно работает (грузится) на реальном железе. Собирает сам себя в конфигурации cross-compilers (набор компиляторов arm, x86 и x86_64 для linux и Windows) приблизительно за тоже время. Включает в себя функциональность as, ld и с-компилятора с препроцессором. Сравним с временем сборки gcc и binutils хотя бы для одной архитектуры, оценим выигрыш во времени сборки сишного кода (приблизительно на порядок) и получается компилятор дла этапа разработки или JIT-компилятор для С.

Ответить | Правка | Наверх | Cообщить модератору

125. "Представлен новый компактный компилятор 8cc"  +/
Сообщение от Аноним (-), 02-Мрт-15, 23:16 
> Ядро 2.4.26 (минимальная конфигурация) собирает за 30 секунд.

Звучит примерно как "чувак в ластах и противогазе взбегает на скользкую горку за 30 секунд". Хорошая заявка на чемпионате сказочных долбо..в!

> И оно работает (грузится) на реальном железе.

А кому ныне всерьез надо ядро 2.4.26? Даже тормозные вендыри SDK нынче реже 3.х уже обычно ядра не используют, а на 2.4 давно кончилась поддержка, в том числе - секурити.

К тому же,
1) Мало-мальски актуальное железо поддерживается какими-то более-менее свежими ядрами.
2) Для старых железок оптимизация кода актуальна как никогда: мощный комп на 10 минут для билдовки кернела найти не так уж сложно, а вот потом работать этот код будет недели, месяцы а может и годы. И как-то совсем не в кассу чтобы он тормозил. Так что скорсть и размер кода для старого оборудования - в приоритете.

> Собирает сам себя в конфигурации cross-compilers (набор компиляторов
> arm, x86 и x86_64 для linux и Windows) приблизительно за тоже время.

Все это круто, но just in case, тулчейн я себе компиляю один раз в фиг знает сколько времени, поэтому время сборки тулчейна для меня далеко не главный критерий. Мне обычно намного важнее какой код будет тулчейн гененирить. Желательно чтобы компактный и быстрый.

> Включает в себя функциональность as, ld и с-компилятора с препроцессором.

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

> Сравним с временем сборки gcc и binutils хотя бы для одной архитектуры,

Ну я собирал оные. И чего? Мне это надо чуть ли не 1 раз за все время работы с таргетом требующим вон тот экзотичный компилер. И, поверьте, экономия нескольких минут на компилежке (тем паче в фоне) тулчейна - далеко не первоприоритетная задача.

> оценим выигрыш во времени сборки сишного кода (приблизительно на порядок)
> и получается компилятор дла этапа разработки или JIT-компилятор для С.

Зато проиграем по качеству кода, в ряде случаев менее оптимальный код вообще в ресурсы таргета не влезет, а кого колыхала скорость сборки при разработке - давно компилируют только измененные файлы, а у больших проектов есть еще и более агрессивное кэширование и распределенные фермы. Так что все это получается весьма притянуто за уши. По факту вон тот же tiny C как бы есть, но реально существует в основном как научный курьез, нежели в качестве чего-то для практического юзежа. Ну вот еще 1 тул такого же плана.

Ответить | Правка | Наверх | Cообщить модератору

165. "Представлен новый компактный компилятор 8cc"  +/
Сообщение от Led (ok), 06-Мрт-15, 01:33 
> Ядро 2.4.26 (минимальная конфигурация) собирает за 30 секунд.

Собери ним x86_64-ядро, а потом приходи.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

166. "Представлен новый компактный компилятор 8cc"  +/
Сообщение от seyko2email (ok), 06-Мрт-15, 09:03 
>> Ядро 2.4.26 (минимальная конфигурация) собирает за 30 секунд.
> Собери ним x86_64-ядро, а потом приходи.

Вообще-то текущий tcc и x86 ядро 2.4.26 собирает только при наложении патча:
Patches are necessary for the following reasons:

- unsupported assembly directives: .rept, .endr, .subsection
- '#define __ASSEMBLY__' needed in assembly sources
- static variables cannot be seen from the inline assembly code
- typing/lvalue problems with '? :'
- no long long bit fields
- 'aligned' attribute not supported for whole structs, only for fields
- obscur preprocessor bug

Some of these problems could easily be fixed, but I am too lazy
now. It is sure that there are still many bugs in the kernel generated
by TinyCC/TCCBOOT, but at least it can boot and launch a shell.

tcc-0.9.23 собирал это ядро, потом его немного порушили и только сейчас tcc вновь может повторить этот подвиг. Возможно некоторые перечисленные выше проблемы в текушем tcc уже решены, но более интересно ядро 2.4.37. Для сборки 2.4.26 нужен gcc не моложе 2.95, более новые gcc с ним не справляются. А вот с ядром 2.4.37 уже можно использовать любые новые версии gcc (3.4.6, 4.1, ...). Так что допиливать tcc интересно именно для 2.4.37. Если получится, то можно будет попробовать его на версии 2.6.9. Ну и далее 2.6.18, 2.6.32, 3.10, ... А вообще-то и clang не очень-то справляется со сборкой ядра без патчей (по слухам)

Что касается x86_64, то у меня 2.6.18 в этом варианте не может работать с WiFI-сетью (в версии x86 всё нормально). Так что можно не заморачиваться с x86_64, пока tcc не научится собирать 2.6.32 И да, меня вполне устроит возможность собирать только x86. Ядро 2.6.9 достаточно быстро (в пределе получаса, но не за 10 секунд) собирается и gcc Ядро 2.6.32 у меня собирается в пределах часа, а вот для сброки 3.10 уже приходится ждать более 2 часов (конфиги от соответствующих ядер RHEL). Для окончательного варианта это не проблема. А вот в процессе разработки такая тягомотина достаёт. Возможность быстро пересобрать ядро в частности сильно бы помогла отладить систему "make menuconfig". Ибо сейчас так правят ядро, что собриается оно только при сильно ограниченных вариантах конфигурации. Шаг в сторону и тут же вылезают проблемы с зависимостями. А перебирать варианты и отлавливать проблемы, когда на одну итерацию нужно от получаса до 2 часов, не реально.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру