Портирование ОС на Aarch64

Действительно, спасибо. Исправил.

Уменьшение времени отклика при передаче данных по UDP

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

Уменьшение времени отклика при передаче данных по UDP

На хосте — обычный арч, на плате — тюнили заказчики, подробностей не знаю.

Я думаю, interrupt coalescing для сетевой карточки может помочь, если приходит много пакетов «разом» (а тут отправляющий хост шлёт их по одному и ждёт ответа), в других случаях это не должно значительно помогать. Или всё-таки помогает за счёт чего-то?

Портирование ОС на Aarch64

Насколько я понимаю, на железке u-boot запускается уже после Arm Trusted Firmware, так что и Embox — тоже.

В QEMU, как я понял, можно подсунуть ATF, но мы этого не делаем :)

Портирование Quake3

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

На ARM для NEON у нас такое есть, а на x86 — нет.

Портирование Quake3

В Mesa действительно есть хорошая поддержка аппаратного ускорения, но она не работает с аппаратурой напрямую, для её использования нужен слой DRM, который и взаимодействует с GPU (и которого у нас пока что нет). Если сконфигурить Mesa с драйвером swrast, она будет, грубо говоря, рисовать картинку в оперативной памяти, без задействования DRM, этот вариант и используется на данный момент.

Реализовать аналог DRM из Linux достаточно сложно, работаем над этим. В данный момент делается драйвер для Vivante GPU на i.MX6. Получить простую анимацию уже получилось, а вот "подружить" драйвер с Mesa не выходит. Там достаточно много подводных камней, когда закончим м.б. накатаю статью по этой теме.

Портирование Quake3

если его нельзя

Можно, это видно на скринах в статье. Графика отрисовывается с помощью Mesa, Mesa реализует OpenGL API.

так сложно использовать

Так же, как и обычно — пишете программу, используя OpenGL API, и компилируете.

Станет понятнее, если прочитать статью чуть дальше первого предложения. Непосредственному использованию самого OpenGL тут посвящено несколько предложений и два листинга кода по 20 строк.

Портирование Quake3

Странно, но KVM тут не помогает. Ещё страннее, что в исходниках qemu сама инструкция (stmxcsr) упоминается и кажется, что и программно всё должно работать. Но что-то идёт не так. Проверил только что — на хосте инструкция исполняется без проблем.

Затрудняюсь сказать, что именно идёт не так.

Указатели в C абстрактнее, чем может показаться

Дело не в третьей переменной, а именно в -O0. С -O1 будет как в примере в статье.

Если посмотреть дизассемблер, с оптимизацией p == q предподсчитывается как 0.

    printf("%p %p %d\n", (void *)p, (void *)q, p == q);
 6b4:   48 8d 54 24 0c          lea    0xc(%rsp),%rdx
 6b9:   48 89 d6                mov    %rdx,%rsi
 6bc:   b9 00 00 00 00          mov    $0x0,%ecx # Вот здесь просто пишется 0 в ecx
 6c1:   48 8d 3d 9c 00 00 00    lea    0x9c(%rip),%rdi 
 6c8:   b8 00 00 00 00          mov    $0x0,%eax
 6cd:   e8 8e fe ff ff          callq  560 <printf@plt>

Без оптимизации делается честный cmp.

    printf("%p %p %d\n", (void *)p, (void *)q, p == q);
 6cc:   48 8b 45 f8             mov    -0x8(%rbp),%rax
 6d0:   48 3b 45 f0             cmp    -0x10(%rbp),%rax # Тот самый cmp
 6d4:   0f 94 c0                sete   %al
 6d7:   0f b6 c8                movzbl %al,%ecx
 6da:   48 8b 55 f0             mov    -0x10(%rbp),%rdx
 6de:   48 8b 45 f8             mov    -0x8(%rbp),%rax
 6e2:   48 89 c6                mov    %rax,%rsi
 6e5:   48 8d 3d 98 00 00 00    lea    0x98(%rip),%rdi  
 6ec:   b8 00 00 00 00          mov    $0x0,%eax
 6f1:   e8 6a fe ff ff          callq  560 <printf@plt>

Указатели в C абстрактнее, чем может показаться

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

If compiled with and optimization level 1, then a run of the program on a x86-64 Linux system prints:

Без оптимизации результат другой.

> gcc main.c
> ./a.out
0x7ffd9dad19fc 0x7ffd9dad19fc 1
> gcc main.c -O1
> ./a.out
0x7ffe4b876ebc 0x7ffe4b876ebc 0

gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)


Существует ли отечественный процессор Мультиклет?

Чтобы избегать ситуаций, подобных следующей:
min(foo++, bar)
С дополнительными переменными foo будет инкрементирована один раз, а без них — дважды.

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

Существует ли отечественный процессор Мультиклет?

Спасибо за замечание!
В исходниках используется именно безопасный вариант, но в статье тоже не помешает исправить.
Ссылка на коммит
Да, тут перепутаны знаки «больше» и «меньше», но позже это было исправлено :)