OberonCore

Вы правы - есть желание попробовать сделать что-то вроде SDK для написания модулей OCF на Ассемблере. Просто я полагаю, что вбивать HEX-дамп в модуль на Обероне - это ещё большее "безобразие".

Это вот чего было???

Это не было, это есть в модулях на Обероне - процедуры в машинном коде. Там вбивается не ассемблерный мнемокод, а непосредственно коды (т.е. шестнадцатеричный дамп).

Ой, - я вас умоляю! "Таки несчастна та Родина, какой нужны герои!"
Оптимизируйте алгоритмы!

Это вы о чем? Пока нет ясности в самом алгоритме.

Разве в этом случае пишут на ассемблере?

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

Какэтотак? А первое (или второе?) thumb rule любого программера? - "оптимизируй, когда разъяснены и отлажены алгоритмы!"

Это я у Вас и спросил, поэтому разрешите уточнить к кому Вы сейчас обращаетесь и нельзя ли спросить его об этом не засоряя этой темы разборками кто что кому сказал.

А это так актуально и животрепещуще - на счёт вазюканья с ocf-файлами? Какому проценту из присутствующих коллег ежедненвно это может понадобиться?

Давайте подождем. В этом и только в этом смысле ирония про страну и героев была неуместной, имхо.

Я говорил не про оптимизацию алгоритмов, а про написание модулей, реализующего низкоуровневый функционал. Писать кусками дампа вместо автокода - это несерьёзно. В приличных компиляторах обычно бывают средства для встраивания ассемблерного кода (в отдельный модуль или инлайн-методом). Хотя в случае BlackBox оптимизация может быть актуальной - он в ряде случаев сильно проигрывает компиляторам в Си в скорости. Недавно проверял на сортировке Шелла - Open Watcom C раза в 3 обогнал BlackBox.

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

Картина с принятым Вами, ScrollLock, подходом страдает отсутствием конкретики. Может быть присутствующие здесь коллеги присоединятся к обсуждению когда появится проект реализации. От какой формы будете отталкиваться, например?

Что-нибудь вроде "примочки" к FASM или TASM для создания нового формата исполняемых файлов или конвертера PE to OCF. Кстати, какие причины помешали использовать стандартные DLL формата PE32 или PE64 (или в случае LINUX - SO), которые может сделать любой адекватный ассемблер и компилятор? Это было бы даже проще - т.к. можно использовать загрузчик операционной системы.

Ну, драсте приехали...

"Обычный DLL" не может экспортировать ничего, кроме точек входа в процедуры. Даже описаний их сигнатур - Вы никогда не сталкивались с проблемой неправильного заголовка к DLL? - и нет никакого способа обнаружить эту неправильность. Я не говорю про то, что экспортировать описания типов вообще невозможно.

Плюс ББ изначально разрабатывался как кросс-платформенная среда (Вин-старый Мак).

Посему однозначно требовался свой формат.

Похоже ещё раздумываете. На мой взгляд предпочтительнее отталкиваться от какого-либо одного формата, оперируя им при загрузке, по примеру встроенного ОСF. Вы, кстати, ранее не говорили, что будете его менять.

На мой взгляд, лучше OCF перелопатить в сторону SlimBinary Франца (с минимальной модификацией) - если сейчас OCF компактнее чем DLL, то в слимах станет и вовсе смешноо размера .
Собственно я намерен этим заняться для дипломной работы, но с текущими темпами ... раки свистеть научатся раньше

Тем не менее, прошу с нами немного координироваться, если Вы будете этим заниматься, так как мы в этом деле сильно заинтересованы...

С, одновременным, написанием варианта загрузчика/бэк-энда? - Одобрям-с!!!