На том же Z80 (ZX-Spectrum, к примеру) двух стековых регистров не было. Но никто не мешал, скажем, читать через POP из памяти, а писать в фиксированный адрес ячейки, что бы без всяких ++. Да, процедуру нужно было разворачивать «руками» для каждой ячейки экрана. Благо, что их было не так много. Зато максимально быстро, на Z80 быстрее сделать было нельзя.

В принципе, использование исключений не ускоряет работу программы на любой архитектуре. Поэтому использовать их в критических местах не лучшая идея. А особенности конкретно Эльбрус делают этот факт еще более значимым. Более детально можно посмотреть в открытых источниках, например здесь:
www.youtube.com/watch?v=8rYfUO1x_MQ

Перед нами, как разработчиками софта, не ставилось задачи выбора платформы. Напротив, необходимо было реализовать качественный и быстрый кросплатформенный код по обработке изображений, одинаково хорошо работающий как на Эльбрус, так и на Intel (Linux + Windows). Мы эту задачу успешно решили.

Причины сугубо рациональные.

Другую версию OpenCV мы не собирали по причине того, что нас интересовала именно EML. Новые фичи OpenCV, наверное, хороши, но для нас пока не представляют интереса. Быстродействие EML представляют намного большую ценность даже при ограниченности функционала версии 3.2 (с которым мы пока не столкнулись).

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

Мы тоже долго ломали голову, как это сделать. На Vulkan, CUDA, OpenCL – просто. На OpenGL мы пришли к тому, что передаем изображение в вертексный шейдер как входные VertexAttibutes. И далее, в зависимости от яркости рендерим в нужную точку одномерной текстуры с соответствующим блендингом. В принципе, работает хорошо. Но количество ядер, выделенных на вертексный шейдер сильно меньше, чем на фрагментный. Поэтому еще и mipmap заранее используем.

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