В том ли я направлении иду.

зачем над линаксом?

А почему нет? Зачем мне сложности?

пили сразу над железом (тестируй над Xen-ом или ещё какой виртуалкой).

Не имеет смысла.

юниядро например, вроде этого — оно правда, на Окамле, но вся фигня типа сопрограмм и одного могучего процесса там есть.

Оно там есть для галочки. Я не вижу смысла делать что-то, если оно не даёт профит.

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

Маловероятно. Мои подходы к написанию не требуют тулзы для сборки.

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

У меня нет задачи пилить ОС. У меня есть задача отлаживать концепции - мне хватает в 95% банального юзерспейса в линуксе.

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

подумай сразу над примерами и бенчмарками

Я не делаю говно.

а то Baremetal OS kernel и на асме есть, с киллерфичами как-то не очень понятно.

А откуда они там возьмутся?

Киллерфича узкоспециализированных вещей всегда одна - они умеют делать то, для чего созданы. Делать проще и делать лучше.

void next_step(int ***map)
{
    int **bmap = init_map();
        int i, j;
        for (i = 0; i < size_m; i++) {
                for (j = 0; j < size_m; j++) {
                        bmap[i][j] = islife(*map, i, j);
                }
        }
        for (i = 0; i < size_m; i++) {
                for (j = 0; j < size_m; j++) {
                        (*map)[i][j] = bmap[i][j];
                }
        }
        free_map(bmap);
}

во первых непонятно, на кой ляд в каждой итерации создавать новую карту? Создай в начале две штуки, и всё.

во вторых, на кой ляд calloc, если ты всё равно её переписываешь?

в третьих, если сделать две карты, то их можно чередовать. Т.е. в начале всё лежит на карте №1, после первого хода основной становится карта №2, а потом опять №1.

в четвёртых, почти во всех строчках пусто. Их можно пропустить. Надо сделать массив флажков, и если строчки n, n-1 и n+1 пусты, то можно сразу анализировать следующую строку. Их можно даже не хранить, тогда поле станет почти бесконечное(1048576×1048576 например).

в пятых, нужно больше const, и меньше звёздочек. Как тут заметили уже, int*** это моветон.

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

в седьмых, для хранения одного бита юзать 32 слишком жирно. Смени хоть int на char что-ли.

в восьмых, можно попробовать ввести ещё точек, например ввести точки «рождающаяся», и «умирающая». Рождающаяся точка считается мёртвой при этом ходе, и живой на следующем. Умирающая наоборот. Тогда второго поля не нужно. Что-бы не переводить рождающиеся в живые надо считать рождающися на нечётных ходах живыми.

много ещё чего можно придумать…

но каждый раз писать example(const int x, const int y, и т.д.)

ничего. Посидишь ночку в поисках места, где у тебя non const изменяется, и будешь писать const с радостью.

Насчёт выделения цельного куска памяти... это же никак и ни на что не влияет... или влияет?

влияет. В сложных программах. А в этой — да, пофиг.

табы мне удобны.

а мне пофиг. Vim сам определяет, ставить табы или пробелы.

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

твой подход слишком сложен. Это минус. Впрочем,выше я уже подкинул идею не хранить пустые строки, тогда это не минус, а плюс: вместо пустой строки просто пишешь NULL в map[y].

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

NULL, тащемта, макрос

речь о стиле, а не о реализации. DEAD (в этом коде)это тоже 0.

но не всегда IDE нужно и не всегда оно будет под рукой.

открой для себя vim. Он тоже умеет свёртку.

{ с начала строки это халявные деньги собственно.

а ещё после { удобно писать коммент, в котором написано, что блок делает. Если свернуть блок, то коммент видно.

Насколько эти глобальные переменные мешают?

не нужно.

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

убивать!

И да, если уж так хочется, то сделай их хотя-бы const int.

Такое чувство что у тебя бомбануло... Только я не понял почему.

оно другим не бывает. Забей.

zc/za? Умею уже года 4.

а ещё после { удобно писать коммент, в котором написано, что блок делает. Если свернуть блок, то коммент видно.

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

Значит я задетектил в тебе бездарного ублюдка, который не стоит моего внимания.

Но как ты это сделал по вопросу «Царь, ты пишешь свое ядро ОС?»?

Тоесть для тебя нет.

Но почему? Как ты понял, что именно для меня - нет? А для tailgunner'a - да?

У меня нет пранировщика процессов

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

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

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

Ты мой код не видел. Зачем ты врешь?

Что ты мне можешь рассказать, кроме пересказа примитивщины, которую ты узнал вчера за партой?

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

zc/za? Умею уже года 4.

дык в чём проблема? Vim'а нет?

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

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

> Хм, я видел, что если они все-таки нужны, им просто префикс g_ дают.

И какбэ мне насрать на то, что ты там видел. Аргументы за g_ будут?

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

7.1.3 Reserved identifiers
1 Each header declares or defines all identifiers listed in its associated subclause, and optionally declares or defines identifiers listed in its associated future library directions subclause and identifiers which are always reserved either for any use or for use as file scope identifiers.
— All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
— All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces
[...]
2 No other identifiers are reserved. If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.

из книг страничек-www

если мы о ускорении жизни то 128(256)битные куски для обработки через 3-4 логических операции - с отдельными доп масками для случая клеток на периметре(либо если торим то масками индексов)

ну и сшивка (16 на 16 разных полей - когда обрабатываем сшивая их нужны шифты слов)

И как тогда ты этот широкий код реализуешь, если на уровне железа это невозможно? Или тебе не обязательно синхронное выполнение, и все проблемы с непредсказуемым порядком доступа к памяти ты где-то еще разруливаешь?

Щито?

Выкати хоть пример. Чего куски, какие операции, какие 16на16разных полей.

Через синхронизацию.

Синхронное управление нужно для выпила синхронизации. В идеале оно должно быть полностью синхронно.

На штеуде это нереалезуемо, но более-менее вменяемую эмуляцию запилить можно.

и все проблемы с непредсказуемым порядком доступа к памяти ты где-то еще разруливаешь?

Какие-такие проблемы - я таких не знаю.

1. храним в 256 битном 256 точек из разных территорий.

при генерации нового состояния Mn=((Mo&&(c==2))||(c==3) можно переписать к виду где вместо счётчика соседей с используем 4 счётчика с0 с1 с2 с3 которые есть биты из с.

тогда для Mn=!c3&&!c2&&c1&&(с0||Mo)

некоторое затруднение как сшить эти территории если мы хотим не 256 разных, а большое единое поле итерировать.