DNF будет переписан на языке C

паскаль на данный момент не имеет ни малейшего отношения к сборке сишных компиляторов

И даже больше, и С с каждым годом имеет все меньше и меньше.

чтобы понять, что сначала собирается простой сишный компилятор, потом libc, а уже потом простой компилятор собирает сложный компилятор. а если нет изначальной платформы, на которой можно кросскомпилять простой компилятор, то он пишется на ассемблере.

Извините, но это опять чушь. Как «простой сишный компилятор» собирает «сложный компилятор», если сложный (GCC) написан на С++, а не С?

И даже больше, и С с каждым годом имеет все меньше и меньше.

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

Ты бы еще у бабушек

так они все равно больше тебя знают - ты даже не отличаешь ядро от драйверов и рантайма

Win32 уже устарел

бгг, на десяточке все то же NT ядро

первое, что делает разработчик железяки - пишет ассемблер. потом пишет компилятор си. или адаптирует gcc под свои коды и вызовы. но так или иначе это смесь ассемблера и си

Про какие конкретно железяки ты говоришь? Можно пример?

бгг, на десяточке все то же NT ядро

ну, это не совсем так. они там ещё в xp раком-боком прикрутили 64 бита. переписывать ядро по-честному им было влом и они сделали очередной компромисс, зато с поддержкой штанов (кучи проприетарных дров). проприетарность им самим мешает. они обмазались задекларированными API и теперь тащат вот это всё с собой.

Ты пропустил (require gregor/time), поэтому у тебя time из racket/base, а не из gregor/time

А можешь на пальцах объяснить как это работает в ракете? В смысле, "(require gregor/time)" скрывает уже существующий racket/base/time? А если хочется оба использовать?

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

так они все равно больше тебя знают - ты даже не отличаешь ядро от драйверов и рантайма

Берем мою ссылку:

https://github.com/Microsoft/Windows-Driver-Frameworks/blob/master/src/framew...

И читаем - «Environment: Kernel mode only». Или ты считаешь ядром только микроядро в NT, а не всякие HAL, I/O, GDI и пр.? Ну тогда да, я не знаю на чем оно написано.

NT ядро

NT это семейство ядер. И менялись они весьма значительно.

Наконец-то DNF с чистой совестью может захавать всю оперативу и процессор, пока kill -9 не отлучит его.

это не так. развивай кругозор. мир не заканчивается в твоей писишечке

А не надо переходить на личности, может я и побольше тебя видел.

а в мире мелкоконтроллеров си очень даже популярен и никаких плюсов там нет

Пойду расскажу другу, что он на работе пишет на том, чего нет, вот он удивится.

А не надо переходить на личности, может я и побольше тебя видел.

ну дык тогда к чему эти нубские вопросы? если видел, то поимей совесть и не притворяйся идиотом.
друзья, родители и бабушки-дедушки не в счёт. я сама писала под мелкоконтроллеры и под многие архитектуры никакой плюсовый компилятор никто делать даже и не собирается. нет смысла.
главная проблема компилятора - распределение ресурсов и оптимизация. если архитектура доселе неизвестная, то просто портировать gcc как есть не получится. всё это добро придётся изрядно переделывать. и это ещё самый простой компилятор, без libc.

если ты освоил си, то питон точно освоишь. а вот обратное неверно.

Что там осваивать в си? Он же предельно тупой. В питоне хотя бы нужно изучить наследование, полиморфизм, замыкания и пр. (и большинство сишников это не осиливает, кстати. Помню, на ЛОРе был эпичных тред про это).

Писать качественных софт - другое дело, и тут с любым языком учиться долго. Я видел много рабочего кода на си, мне можно не рассказывать, будто си выпрямляет руки.

машинное обучение лучше писать на си

В чем-то лучше, в чем-то хуже. Я вижу что его массово пишут на питоне и яве, и писатели эти круче чем процентов 90 опытных сишников.

а в мире мелкоконтроллеров никаких плюсов нет

Ну, это не совсем так.
В интерпрайзном имбеде очень даже юзают плюсы, ради абстракций, в основном.
Если Вы про std/STL, то да, плюсовые библиотеки не юзают.

Или ты считаешь ядром только микроядро в NT

я то тут при чем

https://en.wikipedia.org/wiki/Architecture_of_Windows_NT#Kernel

«Environment: Kernel mode only»

дрова работают в привилегированном режиме - на уровне микроядра

ну дык тогда к чему эти нубские вопросы? если видел, то поимей совесть и не притворяйся идиотом.

Что, простите? Это вы оторвались от реальности.

главная проблема компилятора - распределение ресурсов и оптимизация.

Это наживное. Сходу никто не ставит цель написать супер-оптимальный компилятор, да и ни у кого это не получится.

если архитектура доселе неизвестная, то просто портировать gcc как есть не получится. всё это добро придётся изрядно переделывать. и это ещё самый простой компилятор, без libc.

Вы серьезно считаете, что для новой архитектуры нужно переделывать компилятор? Может быть просто нужно нужно добавить ее поддержку в GCC и сделать кросскомпиляцию GCC же, чтоб сразу получить полноценное решение?

если ты освоил си, то питон точно освоишь. а вот обратное неверно.

Освоить Си не сложнее, чем Питон. Другое дело, что прогер на Питон может быть просто не заинтересован в Си.

Я вижу что его массово пишут на питоне и яве

миллионы мух не могут ошибаться. это к вопросу о том, что легче освоить. но качество на выходе страдает. нельзя малыми усилиями получить качественный продукт. закон сохранения, в некотором роде. либо работаешь много и получаешь оптимальный код, либо работаешь мало, но на выходе нечто вялое и ресурсоёмкое. всё сразу не бывает. конечно, можно притащить уже готовые библиотеки. но в ИИ далеко не все исследования опенсорцные и даже научные работы забесплатно читать не дают. а от нечего делать подобные вещи не пишут. поэтому качественных библиотек в этой области мало.
что касается наукоёмкого софта, то тут ещё есть проблема программистов и математиков. чистые математики, как правило, не умеют писать код. а чистые программисты не хотят лезть в глубокую аналитику и навороченную алгоритмику. институты типа Беркли, где наука и разработка гармонично объединены, встречаются довольно редко. поэтому в большинстве случаев в подобных областях попадаются наколенные программы, написанные математиками, а это поистине страшный код. а программистов в эту степь не тянет, для программиста математику писать скучно.

все компиляторы для микроконтроллеров. любые их реализации. там не пять, там несколько сотен, наверное, можно накопать при желании. первое, что делает разработчик железяки - пишет ассемблер. потом пишет компилятор си. или адаптирует gcc под свои коды и вызовы. но так или иначе это смесь ассемблера и си.

Вот это каша в голове.

Не осилил, к чему эта простыня, но напомню о чем шла речь: о том что якобы на си пишут крутые перцы, а на питоне (и, полагаю, других ЯВУ) тупые обезьяны. Так вот, я говорю о том что это чушь, обратных примеров с обеих сторон пруд пруди, и зависимости тут просто нет (или она мала).

А мало пишут на си просто потому что есть более простые и быстрые способы заработать те же деньги.

я то тут при чем
https://en.wikipedia.org/wiki/Architecture_of_Windows_NT#Kernel

Окей, тогда согласен, был не прав.

А мало пишут на си просто потому что есть более простые и быстрые способы заработать те же деньги.

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

ну давай, ыксперд, расскажи мне, как ты будешь писать компилятор под принципиально новую архитектуру. желательно плюсовый. ведь это же так элементарно, никаких ассемблеров не нужно! сиди себе в идеешечке и пеши, чо уж там.

ну давай, ыксперд, расскажи мне, как ты будешь писать компилятор под принципиально новую архитектуру. желательно плюсовый. ведь это же так элементарно, никаких ассемблеров не нужно! сиди себе в идеешечке и пеши, чо уж там.

Рекомендую ознакомиться:

http://llvm.org/docs/WritingAnLLVMBackend.html

у давай, ыксперд, расскажи мне, как ты будешь писать компилятор под принципиально новую архитектуру.

Лучше ты, почти автор компилятора для Мультиклета, расскажи нам о компиляторах Си, написанных на ассемблере.

сиди себе в идеешечке и пеши, чо уж там.

В общем, да. Где еще писать кодогенератор? Да и ассемблер тоже.

Причем это не только плюсовый будет, но и Rust, и D, и Swift и всякое прочее.

ойойой! а таки если в ваших ЛВМах нету той архитектуры, какая в железяке реализована. например, там много ядер и какие-то сложные шины между ними (я реальный пример имею в виду). и выполение команд параллелится сложно. и выборка команд нелинейная. а отсюда всякие там синхронизации памяти, барьеры и прочее существенно меняются. и в ваши эти стандартные реализации компилятор может не укладываться. у него от природы хардварный паралеллизм встроенный или ещё какая оказия в оптимизации.

ойойой! а таки если в ваших ЛВМах нету той архитектуры, какая в железяке реализована. например, там много ядер и какие-то сложные шины между ними

Эти наши ЛВМы могут хоть в другой язык транслировать:

http://kripken.github.io/emscripten-site/ https://github.com/kripken/emscripten/wiki/Porting-Examples-and-Demos

Где ядер вообще нет. Так что это лишь твоя проблема реализовать бэкэнд, который из IR родит то, что тебе надо.

Лучше ты, почти автор компилятора для Мультиклета, расскажи нам о компиляторах Си, написанных на ассемблере.

я не присваивала себе их разработки, ни на йоту. меня приглашали у них работать, было дело. я пообщалась с разработчиками, узнавала про специфику работы. с точки зрения разработки мне было бы интересно, но с финансами у них было так себе и у нас тогда сотрудничество не вышло. но факт, что ассемблер и компилятор они сами ручками писали. потому что архитектура у них нечто среднее между GPU и CPU. и никакие стандартные компиляторы им просто искаропки не подходят.

Так что это лишь твоя проблема реализовать бэкэнд, который из IR родит то, что тебе надо.

а его, конечно, надо пейсать на паскале. ну да. вот и приехали.

а его, конечно, надо пейсать на паскале. ну да. вот и приехали.

Его надо писать на С++, я же уже дал ссылку.

ага, на С++, который будет компилироваться компилятором, которого нет, но который мы собрались писать, и бэкенд которого написан на С++, который... и далее, в цикле.
писать «бэкенд» компилятора - это и есть основная работа. и львиная её доля - оптимизация. а лексер и парсер - это всё давным давно откатано, если бы в этом была проблема, то и вопросов бы не возникало. а вот как заставить железяку реально работать - вот это вопрос.

ага, на С++, который будет компилироваться компилятором, которого нет, но который мы собрались писать, и бэкенд которого написан на С++, который... и далее, в цикле.

Вероятно вы устали и вам надо поспать. Бэкэнд пишется дома на писишечке, на писишечке же он используется, чтоб собрать уже все что угодно (на С/C++/Rust/D/...) под новую платформу, в том числе и сам LLVM. Меня удивляет, что вы якобы писали под микроконтроллеры и не понимаете таких простых вещей.

Напишу лексический анализатор (или возьму готовый), напишу синтаксический анализатор (или возьму готовый), напишу оптимизирующие преобразования AST (или перепишу готовые), напишу эмиттер assembly для этой твоей принципиально новой архитектуры. Так с какого лешего что либо из этого надо писать на ассемблере?

Ты откуда-то взял, что компилятор - это магическая коробка по преобразование латинских букв в машинный код. На деле же это пайплайн из стандартных композабельных операций; и сам assembly language того во что ты компилируешь там фигурирет как данные, а не как код на котором пишут. Поэтому я и говорю — каша в голове.

Апт ужасная свалка скриптов и мусора.

на каждый чих своя утилита, установка пакетов просто ужасна, правда это уже к dpkg.

Довольно странно слышать такое от пользователя Fedora.

Отнюдь. Я в середине нулевых все новые установки настраивал на использование apt по умолчанию, несмотря на yum. Скорость отличалась в разы + удобные гуи, в отличие от. Потом в репах стали дропать поддержку и выбора не стало.

Посмотрим на код этой libhif. Функция execute_print (не буду сюда копипастить, чтобы аппетит не портить):

https://github.com/rpm-software-management/libhif/blob/master/libhif/hy-hth.c...

Хрен поймёшь, что она там делает. Что надо удалять, что не надо, здесь играем, здесь не играем. И так везде. Уверен, на питоне было строк 5 вместо 40. Няшная сишечка, называется. Лучше бы на жабаскрипт переписали.

реальная разработка процессора местного производства

Теперь понятно. Если это отечественная разработка то вполне допускаю что суровые Челябинские Екатеринбургские программисты легко и непринуждённо «пишут ассемблеры и компиляторы».

В смысле, "(require gregor/time)" скрывает уже существующий racket/base/time? А если хочется оба использовать?

Первая строка #lang. Она даёт пространство имён по-умолчанию. Для языка Racket может быть racket или racket/base.

Дальше все изменения через (require ...) или (define ...). require и define имеют приоритет над #lang (заменяет молча).

Если написать явно (require racket/base gregor/time), то будет ошибка: identifier already imported from a different source

Если хочется оба, то пишется что-то вроде (require gregor/time (rename-in racket/base [time run-time])) или если совпадающих много, то (require gregor/time (prefix-in r: racket/base)) — тогда всё из racket/base импортируется с префиксом «r:».

Всё это позволяет вообще не беспокоиться об именах. Если в API модуля что-то, совпадающее со стандартной библиотекой, но пользователем библиотеки не используемое, то проблем вообще никаких. В крайнем случае все конфликты разрешаются одним prefix-in.

Я указал (require gregor), как написано в доке. и сходу примеры в работали, кроме этого.

Надо для используемых символов смотреть модули. Я в доке щёлкнул по time и увидел вверху описания (require gregor/time). Также в разделе «Date and Time Periods» отдельный модуль.

Надо для используемых символов смотреть модули. Я в доке щёлкнул по time и увидел вверху описания (require gregor/time). Также в разделе «Date and Time Periods» отдельный модуль.

Да, просто такое:

(-hours (datetime 1970) 12)

отрабатало, а:

(+hours (time 22) 4)

Нет. Причем конкретно на той странице не было ничего про (require gregor/time).

наивные хомячки.

не, это реально случай из жизни

это я так ваши гуи чиню

Не мои, я типа как бэкендщик.

уныло это - ковыряться с гуями.

Ну как, если заниматься юзабилити - интересно, если тупо клепать по готовому шаблону - да, уныло. Как по мне - примерно так же уныло, как перекладывать байтики, только что можно использовать более высокоуровневый язык (хоть и не всегда).

Да ну нафиг, я Маркова раньше влёт по манере общения узнавал.

(хриплый Вицин) «НЕ ОН ЭТО!»

кроме C/C++/Python языков нет разве?

качественный продукт.

ресурсоёмкое.

не вижу противоречий.

я не присваивала себе их разработки, ни на йоту.

Я этого и не говорил.

факт, что ассемблер и компилятор они сами ручками писали.

Хм. Кажется, я понимаю, почему у них с финансами так себе.

потому что архитектура у них нечто среднее между GPU и CPU. и никакие стандартные компиляторы им просто искаропки не подходят.

Почти так же смешно, как «все компиляторы Си для микрконтроллеров написаны на ассемблере». Уникальный у них может быть кодогенератор, но это только часть компилятора.

а муравьёв на Земле дофига, гораздо больше, чем человечишек!

кроме С/C++/D/assembler , остальное сделано для лени программистов.

будто лень - это что-то плохое. Жизнь и так слишком коротка.

Няшная сишечка, называется. Лучше бы на жабаскрипт переписали.

Ну так возьми и напиши пакетный менеджер на JS, знаменитый программист ты наш :-) Ещё можешь предложить RedHat свои услуги и свою поддержку, рассказать им о том, каким должен быть пакетный менеджер и на каком языке его ты смог бы написать :-)

кроме С/C++/D/assembler

Да всё, кроме машинных кодов - это излишества :-) Пиши в машинных кодах, не будь лентяем :-)