OberonCore

Спасибо за ответ, за отсылку к Вирту. Я нашел этот фрагмент уже после того, как написал свою статью. И все-таки нашел в себе смелость уклониться от весомого мнения авторитета и попробовать по-своему - в порядке эксперимента.

Да, Struct, form (сокращение от format) и некоторые другие имена и меня тоже сбивали с толку. Особенно поскольку в Сообщении о языке четко сказано, что структуры, в противовес базовым типам - это записи и массивы (даже не процедуры).

В генераторе кода я обнаружил еще такой хитрый прием: вот есть, напр, у каждого объекта привязанная к нему запись .conval, а в ней - поля .intval и intval2. Мало того, что названия никак не намекают на смысл/назначение этих полей - так еще этот смысл кое-где меняется на ходу. Например, было в .intval позиция в тексте, а потом ее - хоп! - и "перепрятывают" в .intval2, а в .intval кладут что-то другое. И потом это другое путешествует по всему исходному коду: смотришь на .intval, и неизвестно, означает это позицию в тексте, или, скам, смещение в сегменте дескрипторов; чтобы понять, нужно делать анализ вызовов процедур. Причем, если obj.form = Comp и obj.comp = чегонибудь, то obj.conval.intval - это что-тоодно, а иначе - совсемдругое.
И хотя это все отлажено и работает - понимать оч сложно. А программы-то пишутся для людей, не для ЭВМ...

Но, конечно, это все - мелкие пять копеек. CP2 продуман, логичен, четко декомпозирован, аккуратно написан и выверен, минималистичен и экономичен. Проштудировав весь анализатор и уже почти весь синтезатор кода, я не могу назвать ни одного критического замечания, кроме невнятных названий типов и полей - напротив, многому научился.

Опробовал интеграцию библиотек с Excel. Работает!
Поддержите Антона тестированием или лучше — финансами → Руб.

не нашел в показанных ссылках, где можно скачать и опробовать.

В первом сообщении есть ссылки: viewtopic.php?f=127&t=6640#p112185

Но вы правы, что надо и прямую ссылку на релиз от 3-го марта дать!
https://github.com/adimetrius/Herschel/ ... mpiled.zip

Он немного устарел, но на скриншоте я именно на нём проверял.

Спасибо

Товарищи, работает ли LLVM достаточно быстро?
То есть, если компилятор КП под x86_64 делать через LLVM, не будет ли он в несколько раз (может быть, даже, в десятки раз?) медленнее, чем компилятор в машинный код?
Есть ли где-то цифры, сравнение?

но зачем? куча десятков мегабайт бинарного мусора, отсутствие не только сишного апи, но и вообще стабильного апи… зачем, мистер Андерсон, зачем? с такими раскладами уж проще взять ofront и делать .so-хи ним.

вообще, llvm — это всегда худшее из возможных решений для любого кодогена.

p.s.: да, будет медленней. без оптимизаций код сильно хуже, чем даже у CP2, а с оптимизациями тормоза. и полный набор прелестей сопряжения с опричной гусеницей крестов.

Если "Y" неоптимизирующий компилятор, то, естественно, да.
Но в сравнении с оптимизирующими -- разница "на глаз" незаметна.
( подробнее - см. в др. подразделе)


Скорее сотен мегабайт, но из них нужны не все. API, действительно меняется, но утилита SWIG способна изготовить "переходник" к нему

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

вообще-то CP2, например, вполне можно отнести к оптимизирующим: он умеет использовать загруженое в регистр значение несколько раз, даже между выражениями. а также умеет в dead code elimination. и, само собой, в constant folding. то, что он делает это не очень агрессивно — никак не выводит его из разряда «оптимизирующих».

p.s.: мой Oberon/Ur делает код ещё быстрее, чем CP2. в смысле, результирующий код быстрее. по скорости компиляции примерно сравним. а он даже в лимитированый CSE умеет.