С чего начать изучение Си и системного программирования

Про Столярова могу сказать только хорошее. Но, наверное, лучше начинать с начала.

Но, наверное, лучше начинать с начала

То есть?

1. Можно взять K&R (2-е издание), выполнять задания и повторять код приведённый в книге для своего процессора и смотреть как будет работать. И разбираться в том, почему работает именно так (особенно указатели, многомерные массивы, структуры и выравнивания);
2. Взять и написать какую-нибудь консольную программу для GNU/Linux или *BSD. Что-то вроде простого файлового менеджера, который бы смог показать файлы в директории, перемещать/копировать, рекурсивно проходить директорию для поиска.

UDP:

3. Иногда подглядывать в ISO/IEC 9899:1999 чтобы понять что говорит стандарт по тому или иному поводу.

Ну С у него начинается во второй части второго тома, до этого идёт паскаль и ассемблер. Можно пропустить всё это, а можно не пропускать. Я это имел в виду.

Ну С у него начинается во второй части второго тома, до этого идёт паскаль и ассемблер. Можно пропустить всё это, а можно не пропускать. Я это имел в виду

Понял.

Что скажете по поводу того же Столярова?

Там же нет упражнений?

http://www.stolyarov.info/static/pdf/progintro_taskbook.pdf

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

Там приводится ассемблерный код соответствующий коду на Си?

Нет. Зачем?

• W. Richard Stevens - Advanced programming in the UNIX Environment, 3rd edition
• Michael Kerrisk - Linux programming interface
• Robert Love - Linux kernel development

По-моему K&R сейчас имеет в основном историческую ценность, учить лучше по чему-то, написанному после 1990 и с учётом C89.

С одной стороны да, с другой - книга небольшая, упражнений много. Удобно учить если C не самый первый язык, я думаю.

https://pdos.csail.mit.edu/6.828/2016/overview.html

Можно взять K&R (2-е издание)

Не рекомендовал бы - устарело оно безнадёжно.

Там приводится ассемблерный код соответствующий коду на Си?

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

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

С ассемблера. Можно под DOS, там сразу будет удобная библиотека прерываний в BIOS/INT 21, прямой доступ к памяти и винчестеру.

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

Почитать распечатай стандарт (или купи в бумаге, он не дорог на самом деле), остальное или не найдешь, или устарело.

С ассемблера. Можно под DOS, там сразу будет удобная библиотека прерываний в BIOS/INT 21, прямой доступ к памяти и винчестеру.

Полезно, но не очень эффективно - архитектур много и не факт что x86 это то с чем придется иметь дело в будущем. Да и не то чтобы шедевр, прямо скажем. Понять общие принципы гораздо важнее. Мои 2 копейки.

Смотри в сторону микроконтроллеров. Там можно ещё найти простые и понятные без бутылки архитектуры. Для начала самое то.

Я с вами согласен. Если речь идёт о «системного программирования» - лучше сперва определиться, ассемблер для какой системы изучать. Но, если для общих принципов, asm для DOS подойдёт, там и литературы полно, в том числе, на русском языке.

Не надо начинать изучение С, не калечь себя и свою психику.

Не надо начинать изучение С, не калечь себя и свою психику.

Гхм. Есть лучшие варианты?

ПыСы: «C»/«C» рознь - скорее не о языке надо говорить, а об API (POSIX etc). Если мы конечно об [около]системном программировании разговариваем.

Полезно, но не очень эффективно - архитектур много и не факт что x86 это то с чем придется иметь дело в будущем

Это совершенно не важно. Даже более того, почти факт, что с x86-16 дело в будущем иметь не придётся. Очевидно же, DOS-ассемблер он привёл не из-за того, что на нём потом придётся писать. А из-за того, что он удобен для изучения и понимания низкоуровневых алгоритмических принципов и хакерского подхода к кодингу, что от архитектуры не зависит.

Понять общие принципы гораздо важнее.

То есть как раз ради этого дос-асм и изучать.

Впрочем, в том что изучать Си лучше с ассемблера, я не уверен. Тем более в условиях нехватки времени.

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

Нет и нет. Синтаксис простой, идеология сложная. А системное программирование состоит из специфики лишь на 10%, остальные 90 - общие принципы.

Где брать годные упражнения

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

Про C можно сказать «easy to learn, hard to master».

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

Именно поэтому лучше начинать с написания простых пользовательских программ «для себя» (включая прошивки для простых микроконтроллеров), а потом лезть в драйверы и т.п.

Не надо начинать изучение С, не калечь себя и свою психику

А что учить-то? Ассемблер, раст, го?

Внезапно, хорошо подойдет стандартный плюс/минус университетский курс: Паскаль, Ассемблер, что-то высокоуровневое. Бери ЯП где минимум или нет UB.

LDD3 и Linux API.
Но это не точно.
Потому, что он как бе простой, но комбинаторная сложность парсинга кода имеет неадекватную сложность.

лучше всего контрибьютить в опенсорс, очень быстро получишь релевантные скиллы и опыт. Только надо выбирать проекты, где получишь фидбек не через полгода))

советую причастится

https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-087...

https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-s09...

https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-s09...

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

Лично я не понимаю что там удобного: загонять человека в tooling которому сто лет в обед и который давно уже никем не поддерживается - так себе идея. Делать syscalls «ручками» не так и сложно (если это именно то что хочется освоить). Asm x86-32 и x86-64 хотя бы актуален (в отличие от) и пригодится с гораздо большей вероятностью. И я бы однозначно заходил с другой стороны: дизассемблировал бы то что компилятор генерит и анализировал с акцентом на «а зачем / почему?» - вот эти знания действительно полезны как с теоретической, так и с практической точек зрения.

Впрочем, в том что изучать Си лучше с ассемблера, я не уверен.

Именно, полностью согласен.

Тем более в условиях нехватки времени.

Его никогда много не бывает.

Тоже упомяну https://man7.org/tlpi/. Там и примеры кода и задания для практики.

Лично я не понимаю что там удобного: загонять человека в tooling которому сто лет в обед и который давно уже никем не поддерживается - так себе идея.

Дело не в тулах а как раз в общих принципах. На современных системах от асма остались встроенные в Си куски и иногда используемые тем же Си отдельные файлы асм-исходников. И это дело не в моде какой-то а в том, что платформа к этому толкает. Такой подход его изучению не способствует. А в реалиях x86-16 прога, написанная целиком на асме - обычное и вобщем-то несложное дело.

Asm x86-32 и x86-64 хотя бы актуален (в отличие от) и пригодится с гораздо большей вероятностью.

Так речь шла не про то, чтобы изучить асм ради его использования, а про то, чтобы проникнуться асмом чтобы потом применять его традиции (но не сам асм) в Си. Так что от какой платформы там был асм - не важно.

Его никогда много не бывает.

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

Из классики — книги по UNIX от Пайка, Кернигана и Co. Есть даже переводы. Хочется больше сетей — Стивенсон, больше ядра — Лав или МакКузик.
Также Столяров выглядит интересным, судя по оглавлению и его персоне.

Кстати, сейчас GSoC 2022 доступен не только студентам, а всем 18+ кто хочет начать что-то контрибьютить в open source. Можно выбрать одну из идей из FreeBSD GSoC. Получится что-то вроде экспресс-курса с ментором :)

Дело не в тулах

Не согласен - Вы условного новичка толкаете решать кучу искусственно привнесённых проблем в духе «как завести DOS на современном железе или поднять его эмулятор», «где найти toolchain под DOS» итд, чем он на этом этапе в принципе озадачиваться не должен, и в будущем эти знания/навыки ему никогда не пригодятся.

а как раз в общих принципах. На современных системах от асма остались встроенные в Си куски и иногда используемые тем же Си отдельные файлы асм-исходников. И это дело не в моде какой-то а в том, что платформа к этому толкает.

Вот здесь всё правда, и я считаю это (текущую ситуацию) фундаментально правильным подходом.

Такой подход его изучению не способствует.

Не вижу смысла знать asm на уровне «могу написать прогу на чистом asm» - трудозатраты будут несопоставимо больше и конкуренты Вас тупо порвут потому как выкатят продукт делающий «то же самое» за время в разы меньшее, пусть он даже будет чутка медленнее на том железе под которое Вы писали свой asm «ручками». За всю мою профессиональную карьеру он мне никогда не понадобился на уровне выше чем «посмотреть почему версия C-шного/плюсового кода A в X раз (на Y%) быстрее версии B». Его ниша - это вставочки (обычно завернутые в intrinsics) в часто используемых примитивных функциях. Вы видите к чему я веду? Важно понимать какой набор базовых операций может исполняться CPU, чего они обычно стоят, как в эти инструкции разворачиваются конструкции C, а специфика конкретного чипа (архитектуры) это дело десятое (за исключением очень узких областей).

А в реалиях x86-16 прога, написанная целиком на асме - обычное и вобщем-то несложное дело.

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

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

Хех, мы все когда-то были молоды и нам казалось что впереди вечность. Я вот начинал с машинного кода под Z80 - там asm уже был переходом на существенно более высокий уровень.

трудозатраты

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

а специфика конкретного чипа (архитектуры) это дело десятое

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

Наверное Вы гениальный программер - я это вижу как неоправданно сложную задачу.

Ты просто не пробовал.

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

Да нет же! Кого нынче парит сегментация, например? Всё сместилось совсем в другую сторону по сравнению с x86-16: ooo execution, referential locality, branch [mis]prediction, cache line bouncing, итд. Реалии изменились. High-perf код тогда и нынче - это 2 большие разницы.

А вот парит! Мы порой сильно заморачиваемся в какую память засунуть тот или иной буфер на Infineon TriCore например. Разные типы памяти, разные размеры памяти, доступ на чтение/запись может отличаться в несколько раз в машинных тактах. Так что вопрос совсем не тривиальный.

А вот парит! Мы порой сильно заморачиваемся в какую память засунуть тот или иной буфер на Infineon TriCore например.

Завтра почитаю что это за чип. Но склонен верить.

Разные типы памяти, разные размеры памяти, доступ на чтение/запись может отличаться в несколько раз в машинных тактах.

И что, реально приходится щёлкать сегментными регистрами like crazy? Или всё таки memory model is flat?

Реалии x86-32/64 таковы:

1. Не уместился хотя бы в L3 - заплати.
2. Залез в память другого сокета - заплати.
3. Умудрился touch’нуть больше cachelines чем необходимо - заплати.

Но это к сегментации о которой Вы говорите имеет мало отношения.

Так что вопрос совсем не тривиальный.

Абсолютно согласен. Я к тому что понимание того как работали чипы 20-30 летней давности мало поможет на практике. И посему для меня лично изучение x86-16 - время на ветер.

И что, реально приходится щёлкать сегментными регистрами like crazy? Или всё таки memory model is flat?

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

И посему для меня лично изучение x86-16 - время на ветер.

Согласен. Вопрос изначально стоял по поводу C. А уж под какую архитектуру его компилять, как там работать с памятью и кешами и т.п. это надо на практике изучать с помощью написания программ и разбора ситуаций когда что-то не работает/работает медленно.