Жуй Уияма (Rui Ueyama) из компании Google в рамках проекта 8cc (https://github.com/rui314/8cc) разработал новый компактный компилятор для языка Си. Задачей проекта является обеспечение поддержки всех возможностей стандарта C11, сохранив кодовую базу компилятора как можно более компактной и простой. Исходные тексты распространяются под лицензией MIT.При разработке больше внимание уделено читаемости кода, который написан с оглядкой на простоту изучения исходных текстов, что позволяет использовать 8cc в качестве учебного пособия для изучения техник построения компиляторов и особенностей обработки Си-кода на каждой стадии компиляции. При этом оптимизация результатов работы пока оставляет желать лучшего и генерируемый код обычно в два или более раз отстаёт по скорости выполнения от GCC. Реализация разумного уровня оптимизации относится к планам на будущее.
8cc поддерживает только сборку для архитектуры x86-64 на платформе Linux. Портирование на другие системы не является первоочередной задачей и будет реализовано только после устранения имеющихся проблем и реализации должного уровня оптимизации. В настоящее время компилятор уже успешно проходит тест собственной пересборки, но так как разработка ведётся всего несколько месяцев, пока не исключается возникновение проблем и ошибок при сборке других проектов.URL: https://news.ycombinator.com/item?id=9125912
Новость: http://www.opennet.dev/opennews/art.shtml?num=41754
>из компании GoogleВ каждое скомпилированное приложение будет добавляться реклама и зодн?
...которые будут требовать гуглхром для показа
А для запуска потребуется регистрация в G+
С обязательным подтверждением через СМС.
Для восстановления аккаунта - скан паспорта и фото на фоне гугло-бука.
Компиляция напрямую в JavaScript позволит реализовать это, а так же ускорить работу в 100500 раз.
Глянул исходники, проблевался.
Не поверил... и тодже проблевался
Не поверил и посмотрел -//-
Я уж было обрадовался -- дай, думаю, тоже посмотрю на корявый код в более или менее большом проекте.
Глянул. Код как код. Обычный сишный код. Кроме for(;;) ничего не удивило.
> Глянул. Код как код. Обычный сишный код. Кроме for(;;) ничего не удивило.Утверждается что там навалом static - "just for lulz".
Про какой static идет речь, статические переменные или функции?
А что странного в for(;;)? Обычное сишное обозначение для бесконечного цикла. while(true) используют обычно те, кто начинал с какого-нибудь другого языка.
Есть два типа циклов: с заранее известным (for) и неизвестным (while) количеством повторов.Количество повторов заранее неизвестно, но используется оператор цикла с заранее известным - с какой целью?
То, что так можно сделать, не означает, что так нужно делать.
> Есть два типа циклов: с заранее известным (for) и неизвестным (while) количеством
> повторов.Где такое говорится про for в языке C?
for каждую итерацию проверяет условие.
Это общая теория языков программирования. Первые называются арифметические, вторые - итерационные. Одни можно реализовать через другие, но с целью повышения читаемости кода (а ведь это заявлено одной из основных целей проекта, так?) не стоит так делать.
А зачем вообще выделяются эти два типа циклов?
http://festival.1september.ru/articles/531460/Как раз твой уровень.
>.1september.
> Как раз твой уровень.Мы поняли, чей это уровень, и откуда есть пошла "общая теория" циклов. </не продолжай, прошу>
А клоун-то все по делу написал, между прочим, что тебя не устроило?
> А клоун-то все по делу написал, между прочим, что тебя не устроило?Да фигню как обычно написал. Басик какой-то и простыня. Нет бы по рабоче-крестьянски на пальцах пацану рассказал. В учебники тыкают те преподы, которые "занимают должность", а работать не хотят. Гнать их в шею надо бы, но что-то все хотят быть певцами ртом, депутатами или юристами-экномистами на край ))
Есть "общая теория", а есть сложившиеся для конкретного языка традиции, к которым привычен любой, кто на нём достаточно долго пишет.У привычки использовать for (;;) - корни исторические, когда bool в C не было (а пытаться его сымитировать через #define/typedef всегда было чревато). А while (1) и подобное - читается явно хуже, чем for (;;) - уж его точно ни с чем не спутаешь. Но и у нынешнего while (true) никаких практических преимуществ нет.
Ты бы ещё на goto в C наехал.
Хуже не-специалистов только бывшие специалисты.Не-специалист хотя бы прислушивается к мнению более знающих товарищей. Бывший специалист мало того, что делает неправильно, так ещё и никого не слушает.
Тип bool был добавлен в 1998 г. Сколько ещё лет должно пройти, чтобы вы признали, что он в языке Си есть и начали им пользоваться? Данный компилятор заявлен как соответствующий стандартам 2011 г., но при этом ложит болт на типы данных, созданные ещё в 1998. Более того, называет это примером того, как надо писать код.
Даже до того, как тип bool был добавлен, существовала теория об арифметических и итерационных циклах, которая прямо говорит, что для циклов без заранее известного количества повторов следует использовать итерационные циклы. А что вам там кажется - это ваши личные проблемы.
Как только размер проекта перешагивает планку в 10 Мб исходного кода, все эти "а мне удобно" одного превращаются в костыли и проблемы для всех остальных. В результате проще получается один раз гвоздями прибить венгерскую нотацию, стандарты написания, оформления и комментирования, чем бодаться с каждым клоуном, навсегда застрявшим в годах своей молодости.
Про это, как и про goto, много писали в 60-х, в т.ч. K&R. Тогда же были созданы все эти гласные и негласные правила.
> Хуже не-специалистов только бывшие специалисты.Зато мы знаем главное - неважно кто хуже, важно кто лучше!
А лучший клован - это ты! Заслужил. :)
Клоун - он клоун и есть. Не доходит до него, хоть тресни. for (;;) читается лучше (быстрее воспринимается взглядом), так как сильно отличается от текста. И это вообще никак не изменилось с появлением bool. И компилирутеся он РОВНО в то же самое, что и while(true) - всё тот же безусловный переход - что ж туда ещё засунешь! А теория твоя применима к Pascal-like циклам, к которым сишный for не имеет ни малейшего отношения.Что до goto - то это была провокация. Теперь совершенно очевидно, что ты на C не писал, если не знаешь, как goto там используется - например для обработки ошибок. Вот так примерно:
e = foo1();
if (e != NO_ERROR)
goto errexit;Впрочем, отдельные персонажи для этого используют опять же бесконечный цикл с break - что куда менее читабельно.
А насчёт венгерской нотации - о да, посмешил.
"А теория твоя применима к Pascal-like циклам, к которым сишный for не имеет ни малейшего отношения"
Pascal-like цикл: for i := 0 to n do
C-like цикл: for(i = 0;i <=n;i++)
Чем они отличаются? Ну, местами символы переставили. С точки зрения выполнения инструкций процессором - ничем...
"хоть тресни. for (;;) читается лучше (быстрее воспринимается взглядом)"
В паскалевском for у меня получилось 12 символов, в сишном - 17 (пробелы не считаем). Почему же тогда ты считаешь, что сишный цикл быстрее читается взглядом? Вообще, эти "гуру" си, которые считают, что написав вместо integer - int, они что-то там экономят и лучше читается код - всегда меня удивляли. Могу подсказать ГЕНИАЛЬНУЮ идею: вместо integer писать i, вместо boolean - b, вместо float - f, вашпе экономия и читаемость, блин :)
> Могу подсказать ГЕНИАЛЬНУЮ идею:
> вместо integer писать i, вместо boolean - b, вместо float -
> f, вашпе экономия и читаемость, блин :)ты опоздал на несколько десятков лет.
> ты опоздал на несколько десятков лет.Видимо, не всем родители рассказывали сказки про те делёкие времена, когда не было ни циклов, ни if-then-else-а, а был один страшный if-goto.
>> ты опоздал на несколько десятков лет.
> Видимо, не всем родители рассказывали сказки про те делёкие времена, когда не
> было ни циклов, ни if-then-else-а, а был один страшный if-goto.Нас учили, что goto в Паскале - это плохо-плохо-плохо. И били виртуальной линейкой по рукам тем, кто не мог обосновать почему не смог обойтись без него.
Много лет прошло, а я пользовал goto всего пару раз ))
Ну что у вас всех ники такие говорящие? Ну натурально Шариков же... Ты вообще как работает сишный for знаешь? Хотя ты, судя по всему, даже не знаешь, как работает инкремент.И ты, дятел только символы считаешь? Ну вот тебе пример - "i" и "l" или "i" и "length". Так вот если ты знаешь, что однобуквенная палка никогда не будет "l", а всегда "i" - то этот символ прочтётся быстрее, чем когда надо присматриваться.Так и здесь - конструкция "for (;;)" достаточно резко бросатся в глаза, чтобы сразу было видно - "бесконечный цикл". Её вообще читать не надо, воспринимается сразу, как иероглиф.
Цикл будет работать так, как захочет компилятор. А ЯВУ, циклы for и while - это просто надстройка над кодом, чтоб такие балбесы, как ты, могли что-то прочитать и написать:)
Что не мешает мне немного разбираться в программировании :)
> "А теория твоя применима к Pascal-like циклам, к которым сишный for не
> имеет ни малейшего отношения"
> Pascal-like цикл: for i := 0 to n do
> C-like цикл: for(i = 0;i <=n;i++)
> Чем они отличаются? Ну, местами символы переставили. С точки зрения выполнения инструкций
> процессором - ничем...for(i = 0; SomeFunction(i); i ++) { ; }
реализуйте через for в паскале.Просто язык Си более гибкий и все сводится к регламенту внутри конкретной группы разработки.
> for(i = 0; SomeFunction(i); i ++) { ; }
> реализуйте через for в паскале.
> Просто язык Си более гибкий и все сводится к регламенту внутри конкретной
> группы разработки.Я бы написал
k=SomeFunction(i);
for...
Так понятнее ИМХО. Иногда лучше расписать i=i+3, чем inc(i,3). Глаз замыливается через часы отлова багов.
> Я бы написалНикто в тебе и не сомневался, клоун-2
Послушайте, уважаемый, а зачем вообще на этом останавливаться? Давайте вообще имена типов не писать, а определять типы мы будем исходя из первой буквы имени переменной.
PS: машу ручкой бородатым программистам.
так и не пишем во многих случаях. потому что лень и auto есть.
Бесконечный цикл - это даже не смешно, руки бы повыдирать из жопы таким программистам, которые используют цикл, для выхода из которого служат операторы goto или break.
У Вас ашипка в слове пОгромист.
c goto не пали контору, пусть неосиляторы сей которые учили вперемешку си и плюсы дальше думают что плюсы это развитие си.
> Хуже не-специалистов только бывшие специалисты.Клоун эпично обгадил самого себя единственным предложением.
> Клоун эпично обгадил самого себя единственным предложением.Скоро напишет учебное пособие: "Как нагадить на себя, не опуская высоко задранный нос" ))
> Тип bool был добавлен в 1998 г. Сколько ещё лет должно пройти,
> чтобы вы признали, что он в языке Си есть и начали
> им пользоваться?спроси у своих хозяев из m$, например. сколько лет должно пройти, пока они сделают в своём гуанокомпиляторе поддержку c99?
> спроси у своих хозяев из m$, например. сколько лет должно пройти, пока
> они сделают в своём гуанокомпиляторе поддержку c99?А до С11 он видимо вообще не доживет.
Образцово-показательные выступления - диалог в рассылке MESA. Бедные вмварщики, никак не могут юзать С11 и даже С99 толком, потому что несчастным проприерасам надо чтобы некий кусок их драйвера жевала вьюжлстудия. И вот они сношаются там. В то время как все линуксоиды там уже с С99 на С11 понемногу переползают, несчастные инвалиды от маздая никак не могут даже С99 использовать. КрЮтые профессиональные инструменты, бэть. Теперь я кажется понимаю почему реактос обречен быть в безнадежной ж..е при ориентации на такие тулсы.
> колько лет должно пройти, пока они сделают в своём гуанокомпиляторе поддержку c99?К 2099-у - это же очевидно. или даже досрочно - к 2098-у.
>чем бодаться с каждым клоуномСамокритика - это хорошо ;)
Клоун, так и скажи, что ты идиоматичного Си в глаза не видел
> Количество повторов заранее неизвестно, но используется оператор цикла с заранее известным - с какой целью?В какой-то ВизуалСтудии while(true) по умолчанию давал варнинг (типа "осторожно бесокнечный цикл"), чтобы не колдовать с прагмами, рекомендовалось использовать for(;;)
Тупо количество символов посчитай. Си создавался во времена, когда память была дорогой и компактность кода ценилась высоко.
> Я уж было обрадовался -- дай, думаю, тоже посмотрю на корявый код
> в более или менее большом проекте.
> Глянул. Код как код. Обычный сишный код. Кроме for(;;) ничего не удивило.Заголовочные файлы все просмотрели?
А чем тебе там заголовок не понравился? Мило и чистенько.
Нормальный код. А уж на for(;;) жаловаться в сях - грех. Самый очевидный и бросающийся в глаза способ нарисовать вечный цикл
нормальный код
> нормальный кодОбфусцированный.
Это из-за того, что съели что-то не то. Нужно аккуратно выбирать что кушаете. Даже в кризис.
А что за «проект 8cc», про который Гугл, например, ничего не знает?
Вроде это один из компиляторов в поставке go-lang. Данный компилятор только допилен до стандарта C11.
> генерируемый код обычно в два или более раз отстаёт по скорости выполнения от GCCКого это волнует, скорость компиляции какая? *Clang face*
кого это волнует если оно умеет только Си?
Это не скорость компиляции, а скорость выполнения скомпиленного кода.Просто ради простоты этот компилятор вообще ничего никак не оптимизирует в сгенерированном ассемблере (а gcc, наоборот, является одним большим накостыливанием микрооптимизаций кода и всяких экстремальных кейсов. Типа «если в массиве нечётное количество элементов не большее сеим, то используем вот такую реализацию цикла»)
> Это не скорость компиляции, а скорость выполнения скомпиленного кода.Читать учитесь.
> Читать учитесь.Ой, всё...
"... генерируемый код обычно в два или более раз отстаёт по скорости выполнения от GCC."
Нет, серьезно, читать учитесь.
Было сказано:
> > генерируемый код обычно в два или более раз отстаёт по скорости выполнения от GCC
> Кого это волнует, скорость компиляции какая? *Clang face*Вы это интерпретировали как "кого волнует, какая скорость компиляции".
На самом же деле это значит "Кого волнует, какая скорость выполнения, лучше скажите, какая скорость компиляции *отсылка к вечной отмазке шланговцев «зато быстро компилируется»*"
Хоть кто-то понял =)
> Хоть кто-то понял =)Вы о чем, девочки?
НО... ЗАЧЕМ?!
Как учебное пособие
> НО... ЗАЧЕМ?!Зачем нужны 2048 дистров пингвина?
Чтобы родственных кровосмешений не было.
> Чтобы родственных кровосмешений не было.Так они же и так от 1го родителя произошли, а потом между собой все пересмешивались и "детей" нафоркали. Самый что ни на есть инцест во всей красе. Эммануэль отдыхает ))
для каждого дистрибутива линукс должно все быть свое от DE, компилятора ...
> для каждого дистрибутива линукс должно все быть свое от DE, компилятора ...Помним про Вавилонскую башню, да?
И чтобы тролльнуть их, БГ сделал так, чтобы башню строили таджики, китайцы и прочие армяне, не понимающие друг друга.
Результат известен ))
> НО... ЗАЧЕМ?!1. В софте, по крайней мере, в той области, где сделан 8cc, сейчас коммунизм (см. GPL).
2. Хороший опыт жития в коммунизме есть в науке - она уже много веков так работает.
3. В науке идеи идут так:
а) Обсуждение в узком кругу.
б) Создание статьи (идея изложена в очень сложно понимаемом виде).
в) Доклады на конференциях и семинарах (полировка идеи в общении с оппонентами).
г) Публикация в монографии (более-менее ясное и простое изложение идеи).
д) Публикация в учебнике (идея очень хорошо переформулирована и проста для понимания).По-видимому, в софте нужно делать что-то подобное:
1. Создавать полупрототип, который сложно, медленно, но делает дело.
2. Оптимизировать - результат сложен, но относительно быстр.
3. Создавать отточенные, упрощённые для понимания программы.
4. Оптимизировать уже их, чтобы получалась простая, но эффективная программа.А с простой, но эффективной программой можно двигаться дальше - усложнять её, добавляя новые фичи. Или же делать программные комплекс, в которой она будет кирпичиком.
Нууу , bison ( yacc ) не использует . flex тоже .
Все сам , вручную , разбирает .
2015 на дворе , блин. А это - студенческий проект номер 10001 .
> Нууу , bison ( yacc ) не использует . flex тоже
> .
> Все сам , вручную , разбирает .
> 2015 на дворе , блин. А это - студенческий проект номер
> 10001 .Я не смотрел внутренности. Если так, то да, смысла в нём нет.
upd. Посмотрел - вы правы. Кстати, без условных lex/yacc компилятор получается сложнее, чем с ними. Да ещё и медленее.
А это ничего что gcc не использует ни lex ни уасс ?Специалисты итить-колотить.
http://en.wikipedia.org/wiki/GNU_bisonGCC started out using Bison, but switched to a hand-written recursive-descent parser for C++ in 2004 (version 3.4),[9] and for C and Objective-C in 2006 (version 4.1)[10]
И причина вообщем была в C++ ( ну и еще паре других языков ) , тяжко его LALR(1) парсить .
Колотить - не переколотить , спецЫалист .
Надо же, один из специалистов освоил педивикию. Уже прогресс.
> Надо же, один из специалистов освоил педивикию. Уже прогресс.Ну да , ну да . Подстраиваюсь под уровень дискуссии .
Ага :)$ find gcc-4.8.3/ -regex '.*\.[ly]'
gcc-4.8.3/intl/plural.y
gcc-4.8.3/gcc/gengtype-lex.l
gcc-4.8.3/libjava/classpath/gnu/xml/xpath/XPathParser.y
> upd. Посмотрел - вы правы. Кстати, без условных lex/yacc компилятор получается сложнее,
> чем с ними.фигня. ничего проще pratt parser и не придумать. зачем для этого городить огород с внешним софтом — не ясно.
> Да ещё и медленее.
как минимум спорно. машина состояний у генераторов получается немаленькой.
> Нууу , bison ( yacc ) не использует . flex тожеуже за одно это получает плюсбесконечность в карму.
а ты — минусбесконечность за отбивание знаков препинания пробелами.
>уже за одно это получает плюсбесконечность в карму.И +9000 кгеморрою и ЧСВ .
>а ты — минусбесконечность за отбивание знаков препинания пробелами.
Извините , счас всё расставлю по фен шую .
И проинтегрирую от минус бесконечности до плюс бесконечности - и познаю дзен.
Парсер - далеко не самая сложная часть компилятора. При этом написанный вручную парсер будет быстрее, и для образовательных целей подойдёт лучше, т.к. даст понимание самых основ, в отличие от flex + yacc. У генераторов парсеров (особенно yacc) традиционно проблемы с выдачей внятных сообщений об ошибках, для чего приходится дополнительно повозиться.
> При этом написанный вручную парсер будет быстреедалеко не факт.
> и для образовательных целей подойдёт лучше
и опять не факт. смотря чему «образовывать».
> т.к. даст понимание самых основ, в отличие от flex + yacc
собственно, как раз не даст. потому как у генераторов ясно видна грамматика, а заодно можно (даже если не сильно хочется, то всё равно придётся, скорее всего) хотя бы минимально прокачаться в понимании матюгов типа LL(1), LR(1), LARL(1), etc.
> У генераторов
> парсеров (особенно yacc) традиционно проблемы с выдачей внятных сообщений об ошибкахO_O
нет, конечно, если путать синтаксический разбор и семантический анализ, то тогда всё будет печально. но зачем?
> И проинтегрирую от минус бесконечности до плюс бесконечности - и познаю
> дзен.Поздно, я уже познал, и дверь запер. Так что "Убежище переполнено. Укрывайтесь в складках местности" )))
> сейчас коммунизм (см. GPL).Совсем плохой?
В FOSS'е процесс создания софта куда интереснее!1. Озаботиться какой-то пустяковой проблемой. Почти не гугля решить, что для этого надо написать программу. "Жаркую. Зимнюю. Твою". Самую лучшую, с блэкджеком и т.д. Отважно сесть за дело, отодвинув в сторону домашку и курсач.
2. Выбрать язык, про который сам месяц назад узнал и даже успел изучить пару операторов и один хакерский метод.
3. Сваять самый бестолковый прототип на замеси хардкода, костылей и вермишели. Лучше, если это будет "не под винду". Не забыть заюзать тот самый хакерский метод, сопроводив комментарием-смайлом "Дарт Вэйдер, колющий орехи правой стороной рта". Опубликовать на гитхабе (git - это же святой Линус писал, вы чо, ребзя!).
4. В процессе публикации, случайно наткнуться на целый раздел программ, в котором твою проблему давно решили десятью разными способами, включая генерацию виртуальной машины на опкодах МК-61 из ЛИСПовых шаблонов через парсер на Рефале.
5. Сильно удивиться, взвыть, презрительно посмотреть на проделанную работу. Обнаружить в руках клок чьих-то волос.
6. Скачать чужие поделия. Вернуть глаза с затылка на место: "Ну кто так пишет?!". С очень большим уважением снова взглянуть на свой код. Выпрямить грудь, принять яги, вальяжно поболтать с отцом. Кстати, клок был его - он просто спал рядом.
7. С удвоенным усердием начать улучшать программу. Застопориться на выборе библиотеки для конфигов, месяц читать умные форумы, вконец зас*ать мозги советами горе-интыпрайзников, скачать 50-мегабайтную библиотеку для хранения единственной опции "MaximizeWindow=true".
8. Обнаружить, что очередная фича требует переписывания всего кода. Снова недоверчиво взглянуть на исходники, предусмотрительно отодвинувшись от отца.
9. Забросить проект, опоздать с курсовой, обозвать декана, сходить в армию, жениться, откопать старый проект.
10. Напиться.Примерно как-то так. :)
Красивый батхертик маздайного быдлoкодераса :)
> В FOSS'е процесс создания софта куда интереснее!
> ...В самый раз!
"Ему хватило ума прожить жизнь как попало" (C)
Слушай, ну смени уже дилера, как-то паршиво тебя торкает, судя по потокам бреда.
Нормально всё, я улыбалсо ))
Руй же.
С китайского Жуй.Учтите китайский: "Жуй (Rui) — китайская фамилия (клан)"
https://ru.wikipedia.org/wiki/%D0%96%D1%...
рано еще китайский учить. наше поколение без него проживет. вот внукам, наверное, уже придется учить в принудительном порядке :)
Это японец, а не китаец.
В китайском у каждой гласной 4 варианта произношения (тоны). И 3 звука, аналогичных русскому "ж". Так что русское "жуй" и китайское "жуй" - это два разных по произношению "жуй".
> С китайского Жуй.японец очень озабочен тем, как его имя звучит на китайском.
к 8-му марта спешили... =)
Меня, как любителю языка Си, это новость порадовала. 8)
Не только тебя одного :)
> Меня, как любителю языка Си, это новость порадовала. 8)В смысле ты любишь смотреть, как работает программист?
или как компилится
>> Меня, как любителю языка Си, это новость порадовала. 8)
> В смысле ты любишь смотреть, как работает программист?Угу. А еще как горит вода и как течет огонь.
> Угу. А еще как горит вода и как течет огонь.Тогда идеальная работа для тебя - быть шефом пожарного подразделения :)
Разжигать пожары и тушить воду, что ли? ;)
> Меня, как любителю языка Си, это новость порадовала.Грамарнаци от такого спряжения застрелился.
> Грамарнаци от такого спряжения застрелился.И придёт МойДодыр с умывальником, и накажет наглеца ))
Когда начнут оптимизировать, станет таким же монстром, как gcc )
Есть Tiny C Compiler и lcc зачем еще один?
Так tcc вроде забросили, а значит не будет добавлен C11
> Так tcc вроде забросили, а значит не будет добавлен C11Для мизерного наколенного компилера это не самая большая из проблем. Для начала там качество кодогенерации обычно таково что оно годится только как действующий макет "а я что-то тоже скомпилять могу!"
Вообще-то пилят потихоньку. А как компилятор tcc фактически turbo cc. Ядро 2.4.26 (минимальная конфигурация) собирает за 30 секунд. И оно работает (грузится) на реальном железе. Собирает сам себя в конфигурации cross-compilers (набор компиляторов arm, x86 и x86_64 для linux и Windows) приблизительно за тоже время. Включает в себя функциональность as, ld и с-компилятора с препроцессором. Сравним с временем сборки gcc и binutils хотя бы для одной архитектуры, оценим выигрыш во времени сборки сишного кода (приблизительно на порядок) и получается компилятор дла этапа разработки или JIT-компилятор для С.
> Ядро 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 тул такого же плана.
> Ядро 2.4.26 (минимальная конфигурация) собирает за 30 секунд.Собери ним x86_64-ядро, а потом приходи.
>> Ядро 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 bugSome 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 часов, не реально.
> Жуй Уияма (Rui Ueyama)Руи Уэяма
Португальское имя Rui транслируется в Руй, а китайское в Жуй. Например, Жуй Ван, Жуй НайвэйRui Ueyama китаец, поэтому транслируется в Жуй.
Точно? А почему в полном имени больше трёх слогов? Да и фамилия звучит как японская.
> Точно? А почему в полном имени больше трёх слогов? Да и фамилия
> звучит как японская.Точно, японец:
> Места проживания
> Карта мест, где жил пользователь
> Сейчас
> Mountain View, CA, USA
> Раньше
> Shibuya, Tokyo, Japan - Matsudo, Chiba, Japanhttps://plus.google.com/+RuiUeyama/about
Так что не Жуй, а Руи.
Lui тогда уж. У японцев L заменяется на R, так как нету буквы такой и звук R произносится как у российского пациента логопеда.
Ты идиот? Японские らりるれろ ближе к русским ра-ри-ру-рэ-ро, а звука L в японском как раз и нет.
В японском нет ни "л", ни "р". Их звук нечто среднее между двумя русскими.Задача системы Поливанова в том, чтобы японец понял японское слово, записанное русскими буквами и прочитанное русскоговорящим человеком. Русское "л" часто проглатывается, а "р" рычащее, в японском звук не проглатывается и не рычащий. Из двух зол выбрали меньшее - "р" - пусть лучше японцев коробит что звук рычащий, но они поймут слово, чем они вообще его не поймут.
> В японском нет ни "л", ни "р". Их звук нечто среднее между двумя русскими.Неверно. Их звук — нечто намого, НАМНОГО более близкое к русской Р, чем к Л. Даже когда они пытаются произнести Л или L, когда говорят не по-японски, всё равно получается именно Р. Или же получается Л даже там, где нужно английское R или русское Р — так же, как русские, изучая английский, порою произносят th вместо S. Ты же не будешь из-за этого говорить, что в русском языке есть этот звук?
> Задача системы Поливанова в том, чтобы японец понял японское слово, записанное русскими буквами и прочитанное русскоговорящим человеком. Русское "л" часто проглатывается, а "р" рычащее, в японском звук не проглатывается и не рычащий. Из двух зол выбрали меньшее - "р" - пусть лучше японцев коробит что звук рычащий, но они поймут слово, чем они вообще его не поймут.
Поливанов тут вообще ни при чем. Вне зависимости от того, выбрал бы он для своей системы Р или Л или вообще Ъ, всё равно этот звук от русского Л намного дальше, чем от русского Р.
Пруф:
http://www.youtube.com/watch?v=Ls7oOxUBbYQ
Если услышишь там хоть один раз "улутоламан" вместо "урутораман" — иди проверять уши.
Говоря ближе-дальше, мы говорим о функции расстояния. Она есть. Но то, как она рассчитывается, не имеет никакого отношения к тому, что была выбрана одна буква, а не другая."Проверять уши" - это типичная ошибка многих начинающих изучения языка. Кратко поясню.
Существует несколько слоёв языка:
1. звуки
2. буквы и их объединение в слова
3. объединение слов в предложенияОстановимся на п.1. Официально наука о звуках языка называется "фонетика".
Европейские языки родственны друг другу, поэтому фонетика обычно учится как таблица соответствия: A - A, B - Б, C - Ц, D - Д, и т.д. В общем случае это неверно. Так во вьетнамском языке существуют три звука, аналогичных русскому "о", каждый из которых имеет 4 (в одном из диалектов 6) вариантов произношения. Т.е. 12 (18) разных звуков вьетнамского языка в русском произносятся как один - "о".
Попытки игнорировать фонетику чужого языка, сводя её к однозначной таблице соответствий, являются грубой ошибкой. Даже у родственных языков произношение отличается. Так напр. русский звук "р" является звонким, рычащим, и раскатистим, а английский звук "r" глухой. Но т.к. в английском нет рычащего звука "r", то можно произносить его с нарушениями без потери смысла. Для примера можете найти интервью Шараповой на заре карьеры и сейчас: она живёт в англоговорящих странах, поэтому её "р" из рычащей русской превратилась в глухую английскую.
Если игнорировать фонетику, то говорить, конечно, можно научиться, но акцент будет просто ужасным. Именно поэтому слова в словарях приведены в транскрипции, а не записаны русскими буковками. Именно поэтому для изучения языка стоит выбирать учебники, в которых используется транскрипция, а не "хау ду ю ду?", "ай эм файн, сэнкс". Последнее "сэнкс" ты вообще правильно не прочитаешь, ну нету в русском звука, аналогичного английскому TH. Нету! И неважно что там тебе слышится.
> Европейские языки родственны друг другу, поэтому фонетика обычно учится как таблица соответствия: A - A, B - Б, C - Ц, D - Д, и т.д.Разве что в клоунском училище. Когда я учился в институте, и еще раньше — в школе, и еще раньше — в детском саду фонетику нам как таблицу соответствия ни разу не преподавали.
не скажу за всю ипонию, но вот у гакта часто проскальзывает смягченное "л" в словах типа "kara". вот ещё пример
kaeranu toki no
http://youtu.be/nmKZFX5AkIw?t=1m49s
Песни — то совсем другое дело. В песнях и "китэ" превратится в "киитэ", а то и вовсе в "кииитэээ", если мелодия того потребует.
Не люблю участвовать в клевании одиночки, но тут не соглашусь. Сколько раз слышал сквозь перевод "аригато" - очень мало отличается от нашего "р". Кстати, чтоб два раза не вставать google://shibboleth+lollapalooza
Съезди один раз в Японию и все эти "слышал", "Рабинович по телефон напел" пройдут как страшный сон.Найдит там японца, который хочет научиться говорить "hello" по-русски и послушай какую "р" они произносят.
Вот здесь японка говорит о своих трудностях изучения L и R в английском, слушать с 5:55 когда она повторяет слова на японском и английском. Так нейтральный (не звонкий, не глухой) звук, одинаково похожий как на "р", так и на "л":
http://www.youtube.com/watch?v=SRgKakkcRQM В других словах этот звук получает огласовку, поэтому кажется что в слове "рамен" звучит чёткая русская "р", но это не так, русское произношение "рамен" японцам жутко режет слух.
> Так нейтральный (не звонкий, не глухой) звук, одинаково похожий как на "р", так и на "л"Нет, явно слышится Р. Да, это не совсем русская Р, но это ближе к русской Р или испанской R, чем к английской R, и гораздо ближе, чем к Л или L. Английская R, кстати, звучит гораздо более похоже на что-то среднее между Р и Л.
> Съезди один раз в Японию и все эти "слышал", "Рабинович по телефон
> напел" пройдут как страшный сон.Я живу в Японии. Японская "р" (звук, добываемый касанием языка к верхним зубам сзади) отличается от р-р-р-р-русской. А "л" (касаясь вытянутым языком верхних зубов снизу) многие не умеют выговаривать (ибо нафиг не нужно).
> Найдит там японца, который хочет научиться говорить "hello" по-русски и послушай какую
> "р" они произносят.Хелло по-русски??? Клоун, выдыхай!
И как бы явственно не звучало Шакуган но Шана, к японскому ближе Сякуган но Сяна. Проверено. "Шакуган но Шана" не понимают. Вообще не понимают. А "Сякуган но Сяна" понимают, хотя у них произношение этого занимает где-то наполовину меньше времени, чем у меня :-). У них какие-то короткие "ся" получаются :-).
Брехня. К японскому ближе Шякуган но Шяна. А что Поливанов не догадался, что это только жы-шы пишется с И, а жа-ша вовсе не пишутся через Я, это уже его проблемы.
Японцы считают иначе. Разговор закрыт. Тур. поездка в Японию "всё включено" на 2 недели стоит сейчас ~200 т.р. На open source и GPL таких денег не заработать, поэтому я туда еду на сакуру (опять), а ты сиди и размышляй что на что похоже дальше. Не отвлекайся. GPL твоё всё :-)))))))))))))).
> Японцы считают иначе.Исчерпывающий список японцев, считающих "иначе" в студию.
> я туда еду на сакуру (опять)
Охренеть какой серьёзный аргумент в лингвистическом споре.
А где там в исходниках глянуть непосредственное формирование исполняемого elf файла ??
Он запускает ассемблер в main:
execlp("as", "as", "-o", outfile, "-c", asmfile, (char *)NULL);
Недурственно. Он компилит местами лучше, чем pcc, который здесь хвалили пару месяцев назад. При том, что pcc пилят десятилетия.
когда уже бинарные чиста в стандарт внесут и соотв в компилер?
числа, извините очепятка
Исходя из написанного, вы - очепяток. Не знаю что это, но надеюсь что-то очень обидное.
нет, не обидел, спасибо за урок
из новости непонятно, он нацелен на обеспечение всех возможностей С11 или уже обеспечивает?
> из новости непонятно, он нацелен на обеспечение всех возможностей С11 или уже
> обеспечивает?Он компилится только компилятором, который поддерживает -std=gnu11 или хотя бы -std=gnu1x, значит в его исходном коде есть что-то, требующее С11. При этом он умеет компилировать сам себя, значит [как минимум] некоторые возможности С11 он уже поддерживает.
годное название )
:-)8<
скоро написать компилятор С будет курсовой
Уже: http://sources.codenet.ru/download/3508/Translator.html
неуежли сдал? а как же оптимизация? сейчас вроде всё в неё упирается
Это только с дивана жизнь кажется простой. На деле даже парсер (при всём обилии теории) - проблема (хотя бы тех же рекурсий). Затем, через пень-колоду написав грамматику, переходишь к геморою построения АСТ, т.к. оно должно быть не только исчерпывающим и удобным, но и стремительным как бабка перед единственным пустым местом в трамвае! Т.е. теперь имеем ещё тиски по скорости для адекватной поддержки IDE. Затем кодогенерация: обход дерева - не самое сложное, тут надо представить код так, чтобы потом оптимизатор не свихнулся.
Короче, стоит только реально взяться за компилер и даже "язык черепашки" становится чертовски неподъёмной задачей.
Так занять пустое кресло тоже бывает непростой задачей. Если это трамвай - ну там еще зад можно притулить. А если это свободное кресло пилота истребителя или КВСа гражданской авиации - попробуй еще пристрой туда свой зад. А если это космический полет - конкурс ж..п на место и требования к ж...м могут быть не самыми тривиальными. Вот видишь - может быть сложно даже плюхнуть свой зад в кресло, если хочется кресло получше трамвайного.
Рей Аянами молодец.
Молоток парниша. Привязка под python будет? )))