OberonCore

Кстати, кто-нить видел документ от Intel об архитектуре Intel 64? Я нашел только AMD-64.

http://www.intel.com/products/processor/manuals/
Не оно?

Похоже - оно. Спасибо. Я как-то в продукцию не лазил...

Илья Евгеньевич, а более внятно выразить позицию нельзя?

Я считаю, что целые типы трогать не следует. Оставить разрядность, как есть.

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

Спасибо.

Тогда нагрузка машинного слова ложится на LONGINT.... но SET нужен... второй.... тогда уж LONGSET

Так точно.

По поводу "просадки" целочислодробительных мест за счёт работы не на полном слове. Как раз такие фрагменты - редкая частность; пусть переписываются для выжимания полной скорости. Можно также ввести тип NATINT (native integer), который как раз генерируется в оптимальную разрядность всегда. Пусть, кому надо для двух платформ на оптимальной разрядности работать, его используют. В модулях старых вообще объявят TYPE INTEGER = NATINT.

Один всё-таки есть. NATINT не надо вводить.

Итого, КП лучше вообще не трогать получается. Только ввести некоторые типы... возможно. Хорошо.

А что с реализацией загрузки-выгрузки модулей и прочей системной механики? Что-нибудь поменяется на новой архитектуре? Или это только в привязке к ОС (кто-то говорил про другую обработку исключений в Win 64)?

64 битная Linux версия BB была бы очень хороша для веб-программирования (FastCGI), особенно если снабдить подсистемами для работы с FastCGI и mySQL, вот мы и получили бы популярность BlackBoxa.

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

Уважаемые коллеги.

Компилятор BlackBox, судя по всему, сидит в файлах DevCPXXX.
Однако, попытка отрыть соответствующие файлы в папке Docu дает ответы типа



Может быть, в качестве первого шага по переносу BlackBox на 64 бита стоит изучить, как сделана система для 32 бит?
Изучить и документировать эти модули?

1. В качестве первого шага это технически будет несложно, достаточно поставить и изучать обычный BlackBox.
2. Если кто-то заинтересованный работает преподавателем в вузе, то может эту работу можно распределить в качестве каких-нибудь курсовых/дипломных среди студентов,
причем изучение каждого модуля подсистемы может быть отдельной задачей.
3. После получения понимания того, как работает существующая подсистема, будет намного легче осуществить перенос BlackBox на 64 бита.

По структуре компилятор ББ --- это OP2, на него где-то должна быть документация (репорт ETH), но сходу не скажу где именно. Нужно ссылку найти. Короткий вариант можно посмотреть здесь: http://oberoncore.ru/library/op2_a_port ... 2_compiler

Нашёл и загрузил туда же полный.

Интересно. Почитаем.

По-поводу системной механики: по идее BlackBox 64 должен бы также перейти к 64-битной адресации памяти, что позволило бы преодолеть существующее ограничение максимальной доступной памяти составляющее в BlackBox 32 около 1,5 ГБ.

По идее, в текущей 32-битной версии модуля Kernel размер памяти зашит в коде (AllocHeapMem):

Так что, теоретически, размер можно увеличить, не переходя на 64-битную архитектуру.

P.S. А зачем требуется так много памяти сразу?

Если адресация использует INTEGER, то размера больше чем 2 ГБ в любом случае не получится.

Есть много задач, где много памяти не помешало бы, ну, например, многомерное адаптивное Монте Карло интегрирование http://arxiv.org/abs/physics/0203033 или, скажем, обсуждавшееся уже решение многомерных уравнений в частных производных http://forum.oberoncore.ru/viewtopic.php?f=12&t=3153#p57384.

Почему 2 Гб, а не 4 Гб?

Я в этом вопросе ни в коем случае не специалист, но должно быть как-то так:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits