OberonCore

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

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

Товарищи, либо вы невнимательно читаете, либо я прочёл несколько иное. Речь шла о портировании нового кодогенератора из AOS...

Борис, Вашего недоумения не разделяю. Немного ранее речь шла о новых возможностях кодогенератора из AOS тоже:

Была высказана мысль, что эти возможности можно получить не прибегая к модификациям кодогенерации в Блекбоксе. Но получению работающего кодогенератора по типу AOS-кого она препятствий не создает. Не так ли, info21?

Вообще-то я имел в виду, что кодогенератор в ББ не поддерживает CPU-инструкции для процессоров после 486-го, в то время как кодогенератор в Aos должен как минимум поддерживать P6. И обновление кодогенератора должно бы привести к ускорению FPU-вычислений.

Что касается векторных инструкций в Active Oberon на языковом уровне, то это, конечно, отдельная тема.

И на каком языке должны быть написаны эти библиотеки?

Поддержка каких инструкций более поздних CPU необходима? Пентиумовских CPUID, RDTSC и CMPXCHG8B Или CMOV* для Pentium-II ? Думаете они ускорят работу блэкбоксовских программ?

Разумеется ускорят, хотя и не сильно.
Например тут можно почитать что некоторые инструкции неоправданно тормозны на сегодняшних архитектурах:
http://www.agner.org/optimize/
Причем эти инструкции частенько используются распространенными компиляторами типа Delphi (сравнение флоата и целого насколько помню), а кое-где и даже вполне свежими MSVC.

Что касается векторных вычислений (SIMD), то тут можно подумать о чем-то навроде интринсиков.

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

Я (пока для себя ) этот вопрос прорабатываю.
(К сожалению, в силу жизненных обстоятельств, с довольно большими перерывами. )
Основная проблема для меня не в том, как делать компилятор, а в том, каким он должен быть. Отсюда и вопросы.

Возвращаясь к старой теме: есть также субсистема ofront, представляющая собой Oberon2-to-C транслятор, работающую под линуксом или под Windows/BlackBox. C-код, правда, генерится для unix (linux) платформ, но наверняка после минимальной доработки мог бы также генериться и для cygwin.
Транслируемый код при этом должен быть написан именно на Oberon-2, компонентный паскаль в выложенной на сайте http://www.software-templ.com версии не поддерживается. Если ofront доработать до транслятора Component Paskal-to-C, то хотя транслятор, конечно же, не так удобен, как родной компилятор, но при необходимости встраивать в не-обероновские библиотеки неграфических модулей, разрабатываемых на BB, такой путь также мог бы представлять определенный интерес: разработанные в BB компоненты транслировались бы в нативный код для целевой платформы с помощью ofront и любимого оптимизириющего C-компилятора для этой платформы.

Если я правильно помню, в BlackBox можно включить опцию, чтобы компилировалось в Оберон-2.