OberonCore

Ещё одно дополнение по результатам небольших исследований. Если в первом случае (когда всё ok) заменить локальную переменную ch на такую же, но глобальную, то так же возникает исключение #5: whole overflow. То есть, различия в оптимизации выражений возможно не связаны с тем, как получено значение char, а связаны с тем, где это значение размещено: на стеке, в регистрах или в статической памяти.

Нет, на этапе компиляции вычисляется только первое присваивание. Если включить PROCINLINE, то будет вычисляться и второе присваивание тоже, и тогда вы увидите предупреждение о том, что в данном месте будет исключение "whole overflow".

В этом, действительно, есть различие между compile time и run time. Компилятор вычисляет константные выражения не так же, как код, который он генерирует. Компилятор всегда работает с LONGINT, а генерируемый код - в соответствии с описанием языка.

Да, действительно. Чтобы уж окончательно распутаться, разделил переменные:
Отчёт:

Евгений и Александр, спасибо! Вопрос закрыт.

Оказывается, 6 февраля вышла бета 2, и некоторые проблемы, сообщённые по почте и через форум, были устранены.
Источник: http://www.excelsior-usa.com/forum/topi ... #entry4526
Надо проверять.

Посмотрел вторую бету. Новых ошибок (из моей коллекции) не исправлено. Добавлены ранее забытые проекты в Samples/vterm. Удалён файл с описанием "учебной лицензии".

Спасибо за сообщение. Качать-переходить тогда не буду. Не вижу смысла суетиться.

Кто-нибудь может просветить?
Есть список библиотек и заголовков к ним, но полностью отсутствуют исходники. Пойди догадайся, что IO.RdKey реализована через межпоточную блокировку и крайне тормозит.

import32.lib
libts.lib
libtsmt.lib
libxds.lib
libxdsmt.lib
vterm.lib
xds26i.lib
xds26mi.lib
xstart.lib
xstartc.lib
xstartd.lib
xstartx.lib
xts26i.lib
xts26mi.lib

А в чём просветить-то? Где исходники добыть, или что?

Ну да. Где глянуть реализацию RTL и стандартных библиотек. Или предполагается работа с чёрным ящиком?

Нигде, это "ноу-хау". Читайте документацию. Скажем, либы с буквой "m" в суффиксе - это от слова "multithread".
Если интересны подробности, читайте xc.tem.

Ага, спасибо. Жаль, конечно, что такое "ноу хау". В отладчике реализацию не удобно выискивать. Проверял на Graph-е и IO.

Народ подскажите: является, ли, сборщик мусора в трансляторе XDS-C для Windows совместимым с многопоточным программированием?

Да, см. раздел "Creating multithread programs" в файле xc.hlp.

Так это справка для компилятора Native XDS, а справка к транслятору XDS-C хранится в файле XM.HLP, и там про совместимость с многопоточностью сборщика мусора чётко ничего не говорится, вот я и спрашиваю... На официальном форуме на этот вопрос пока не ответили...

Хех. Прошу прощения, не внимательно прочитал вопрос.

Не знаю, как работает транслятор XDS-C, но если результирующая программа опирается на те же либы, что и скомпилированная Native XDS, то достаточно убедиться, что она использует libxdsmt.ilb (для статической линковки) либо xds25mi.lib (для динамической). Буковка "m" в названии означает "multithreaded". Собственно, это и есть подключение сборщика мусора вместе с многопоточной версией оператора NEW и т.п.

При динамической линковке, соответственно, потребуется xds25m.dll, а не xds25.dll.

При компиляции Native XDS достаточно включить в проектный файл опцию "-multithread:+". Подозреваю, что в XDS-C нужно сделать то же самое, и всё заработает.

Спасибо за ответ.

Тут еще в одном месте случается invalid location...

Собираем, запускаем

CreateFileMappingA выполняется, но на выходе из вызывающей ее функции трап. То же с OpenFile.

Что-нибудь можно сделать?

Ваш баг у меня воспроизводится. А если я использую проектный файл со своими настройками компилятора, то Ваша программа работает без ошибки. Попробуйте поковыряться в настройках компилятора.

Выкладываю проектный файл.