OberonCore

Товарищи, всё таки интересно.
Давайте прикинем, что нужно менять, если переходить на 64 бита, кроме непосредственно кодогенерации.

По изменениям в КП, сразу напрашивается перевод INTEGER на 64 бита - ибо машинное слово. За ним идёт SET. Что ещё? Нужно всю систему типов ведь тогда двигать... LONGINT в 128 выводить (тогда поддержка на SSE ляжет, а сейчас он при помощи FPU обслуживается)?

Какие есть соображения?

Смена разрядности целых, на самом деле, всегда небезболезненна.
И неизвестно, каким боком может выйти (какие где допущения в коде сделаны).

Отсюда вопрос: а если не двигать целые?
Да-да, я знаю, что "по-хорошему надо двигать", но всё-таки.

Целые, как и SET, ни в коем случае нельзя трогать.
Ни по-хорошему, никак.
Они были зафиксированы для переносимости, и это должно быть сохранено.

Если нужно 128 бит -- это HUGEINT.

Да, я бы не двигал.

Эх, было бы вообще здорово, если б само название типа явно указывало количество отводимых бит под хранение (INT32, INT64, ...). А так, да, "фиксированные" типы - добро.

Интересно, кстати, чем вызван интерес к 64-битному BB...

К сведению, следующая версия Delphi вновь будет только 32-битной. Негодование нарастает. Зато обещают кросс-платформенность...

Это ещё почему?
INTEGER и SET опираются на машинное слово - как их не двигать?? Операции усложнять тогда тривиальные?

И для совместимости с чем? У КП - только с Java. Больше ему не с чем быть совместимым. А речь именно про КП.

С самим собой:

В КП INTEGER - именно 32-битный, поскольку никакого другого целого типа указанной разрядности в нём нет. И куча кода в самом ББ пользует INTEGER, неявно предполагая его 32-битность (тот же Stores, весь Host). По хорошему то оно конечно надо, но нельзя.

Просмотр Сообщения о языке вызвал вопрос:
а кто сказал, что в КП целые типы фиксированы? В том же Сообщении о языке есть основной раздел:

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

Прикладные программы должны писаться опираясь на основной раздел, как раз это - гарантия переносимости. А если кто-то при написании кода подглядывал в приложение - это его проблемы. Более того, если оставить жёсткую привязку типов, то мы и порушим переносимость, ибо начнём опираться не на основной закон, а на некие подзаконные акты.

Так что именно ради сохранения переносимости и универсальности мы должны сдвинуть целые типы, причём не добавляя новых типов (LONGINT->128, INTEGER->64, SHORTINT->32)! Если делать в духе Оберона, то нужно вводить псевдомодуль SYSTYPES, в котором и будет куча INTxx, REALxx, SETxx и беззнаковые. Тогда полностью переносимым будет считаться только тот код, который не использует SYSTYPES и SYSTEM.

В XDS типы с размером в имени вынесены в псевдомодуль SYSTEM.

SYSTYPES - только типы, своеобразный индикатор ориентированности на железо и вообще внешний мир, SYSTEM - потенциально опасные вещи

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

1) название языка (чтобы наплевать на совместимость);
2) названия целочисленных типов (ЦЕЛОЕ8, ЦЕЛОЕ16, ЦЕЛОЕ32, ЦЕЛОЕ64, ЦЕЛОЕ128).

Почему? Потому что раньше дела действительно обстояли именно так, при скачке 16-32?

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

Во Free Pascal используется следующая система именований типов:

Таким образом, можно иметь типы, жёстко привязанные к размеру: например, INT32, INT64, а тип INTEGER может быть принимать значение INT32 или INT64 в зависимости от архитектуры. Причём, типы INT32 и INT64 останутся внутри реализации КП.

Мне кажется, что именно по то причине, что целым типам не даны точные определения, их можно и нужно менять когда меняется архитектура. Диапазоны типов имеют значения, характерные для некоторой архитектуры (в данном случае, для x86 32 bit). Но это не означает, что диапазоны нельзя расширять. Тогда и не нужен HUGEINT.
А в чём проблема с переносимостью?
Даже у Вирта в "Алгоритмах и структурах" можно прочесть:

Проблема, как всегда, в том, что буквоедство не хочет видеть твёрдости реальной стенки, которую надо пробивать Вот действительно так. Буквы буквами, но типы - это то, чем язык связан с реальной железкой. Тут неизбежно будут проблемы.

Как раз в Обероне типы изначально планировались по возможности изолированными от железа. Иначе какой смысл в описании имеет строчка ?
То, что при этом не ввели "железных" типов, вроде того же INT32 - это большое упущение, которое порождает теперь проблемы.

Где обязательно возникнут грабли: Stores.

Совместимость по форматам файлов документов должна сохраниться обязательно, но и интерфейс модуля должен остаться неизменным/совместимым. И получится что Stores.Writer.WriteLong будет принимать 128-битный LONGINT, а в файл реально писать должно 64-битное целое. в лучшем случае придётся долго и цветасто описывать эту особенность в документации.

Уже было, уже описано:
и т.д.

Ситуация немножко другая. Тогда был один разработчик, который сказал "мигрируем" - и все мигрировали. Теперь же разработчик ничего не говорит, а новая версия возникнет сбоку (если возникнет, конечно) - поэтому будет сосуществование. Другими словами сейчас и интерфейсы базовых модулей, и формат документов должны остаться неизменными