Оберон-клуб «ВЄДАsoft»

Командная строка точно такая (dll вместо console)?

Compiler32.exe test.ob07 test.dll dll -pic
или
Compiler32.exe test.ob07 test.dll dll -reloc

И какой просмотрщик?

Всё по инструкции делаю, всё правильно собирается, это просмотрщик тупит. Скрипт на питоне правильно обращается и отрабатывает. Правда, толку пока никакого.
10 миллионов итераций показали, что внутри питон работает быстрее ровно в 2 раза, чем лазить в стороннюю библиотеку с дикой конвертацией параметров. Если математика тяжёлая будет -- тогда да. Сейчас 85% смысла потерялось.

_________________
Действия профессионала предсказуемы. Но в мире полно любителей!

За Обероном всё ещё остаётся строгая статическая типизация. Как я сегодня костыли для питона изобретал -- это надо видеть. Метод выдавливания багов из питонячьего кода -- подражать Оберону. Тупо и беспощадно. Но даже мой оберон-стайл в питоне -- не поможет, пока исполнение не дойдёт до этого куска. И это просто всё.
Что касается моего результата по времени, сегодня -- для себя сделал вывод, что чтобы внешний вызов себя оправдал -- необходимо в DLL выполнить как минимум 8-10 операций. А лучше -- больше. По потреблению памяти, безусловно -- Оберон делает питон просто на ровном месте. Есть у меня куски, где тут Оберон можно прекрасно притулить. В общем, пока я из графика выбиваюсь, отстаю, придётся кряхтеть на выходные. Сегодня уже завёл сервер в облаке и начальство смотрит на меня с вопросом "ну что там у нас?". А у нас просто говнокод)))

_________________
Действия профессионала предсказуемы. Но в мире полно любителей!

Устранены практически все недоработки (кроме ассемблера). Соглашение вызовов win64 поддерживается, но работает недостаточно эффективно, поэтому пока [win64] используется только для связи с внешним миром, а внутри применяется собственный формат вызова на основе stdcall. Я протестировал прямые вызовы на системных функциях Windows64, обратные -- с использованием компилятора Patchouli -- всё работает. Поддерживается генерация DLL. Почти исключен сопроцессор x87 (используется только для редких операций PACK/UNPK). Улучшена обработка длинных констант.

prospero78su
Я всё же вернул обратно свой старый код (хотя я принял некоторые предложенные тобой улучшения), потому что всё это было несвоевременно. Пока рано приводить имена в порядок -- там всё еще очень нестабильно. И делать это надо согласованно и не так быстро. К тому же, у меня нет гарантии, что ты это доведешь до конца.

Да, без проблем. Ты главное, пили старательней)))

_________________
Действия профессионала предсказуемы. Но в мире полно любителей!

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

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

32-битный бэк-энд по качеству не очень много уступает Блэкбоксу (на тестовых задачах 80-90% от производительности ББ).
64-битный -- мало отличается от Patchouli, но всё же пока чуть хуже.

Поддержка Windows32/64 реализована полностью, как было задумано: exe, dll, импорт/экспорт процедур.
Поддержка Linux32/64 -- частичная: без dll и без импорта процедур. Последнее, впрочем, не очень критично: все программы импортируют dlopen и dlsym, с помощью которых, можно получить адреса внешних функций. Пока не знаю, буду ли я доделывать поддержку Linux. После перерыва (если не потеряю интерес), скорее всего, буду смотреть в сторону контроллеров. Собственно, для контроллеров, я и начал этот проект. Поддержка x86(64), Windows/Linux мне нужна, главным образом, для самодостаточности компилятора.

Ого, издалека зашли. Хорошо, что начали не с написания ОС.

А какие контроллеры предполагаются?
Для некоторых типов ARM есть уже неплохой, но платный, Astrobe...

Издалека. Что ж, бывает, люди делают что-то непрактичное. Практичней было бы взять Ваш транслятор и приспособить под свои нужды. Еще практичней -- вообще забить на Оберон. Кодогенерация для контроллеров -- это конечная цель проекта. Без достижения этой цели, я не буду считать проект завершенным. Но есть и другая, попутная, задача: построение мультитаргетного компилятора с линейным (не AST) промежуточным представлением (я как-то скептически отношусь к синтаксическим деревьям). Есть Оберон-реализации с построением AST, которым это дерево не помогает, а скорее мешает (усложняет добавление нового бэк-энда). Ну, мне так кажется... А поскольку никаких сроков мне установлено, я могу подходить к решению задачи сколь угодно издалека, как мне будет удобно.


Пока не выбрал. Окончательно решу непосредственно перед имплементацией. Если есть какие-либо предложения, советы по выбору типа контроллера, можете высказать, нет -- я сам выберу. Пока можно сказать, что это должен быть достаточно распространенный контроллер (чтобы не было сложностей с покупкой) и он должен быть 32-битный. Наличие уже готовых компиляторов меня не смущает. Astrobe -- коммерческий и (кажется) только для Windows. Компилятор Ширяева привязан к Блэкбоксу и имеет неясности с лицензией. Я же, предполагаю сделать инструмент пусть хуже по качеству кодогенерации, но полностью свободный и не привязаный к определеной ОС/среде.

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

Самые распространённые микроконтроллеры -- это 8-битные типа MCS51 или AVR, или 16-битные PIC (есть, правда, 32-битные PIC, но там ядро MIPS).
32-битные системы уже трудно назвать микроконтроллерами, в голову лишь Cortex-M приходят, а там уже конкуренция с Астробом. Ну и эти MIPS-овые PIC'и...

Кстати, рассматривалось ли использование сторонних бекэндов типа LLVM или QBE ( http://c9x.me/compile/ )?