Embarcadero, вероятно, предоставит руководство для бета-тестеров. Но вот несколько идей:
Распределение памяти, выравнивание, куча и стек. 32-разрядный может использовать до 4 ГБ (ну, 3,5) адресного пространства в 64-разрядной версии Windows с переключателем /LARGEADDRESSAWARE: Delphi64 должен иметь возможность использовать гораздо больше. Попробуйте выделить 8, 16 и 32 ГБ. (Даже если у вас меньше ОЗУ, выделение должно работать, поскольку это виртуальное адресное пространство.) Теперь считывайте и записывайте значения в него в определенных местах: проверьте выделение и все указатели работают. Посмотрите, что Process Explorer сообщает для приложения. Проверьте свой стек: он работает сверху вниз, в отличие от кучи - как он выглядит, по каким адресам он используется? Как выглядит 16-байтовое выравнивание? Сохраняется ли это выравнивание для всех внутренних функций Паскаля или только для тех, которые вызывают внешний код? В 32-битном VCL было несколько фрагментов кода, которые были небезопасны для адресов размером более 2 ГБ. Это было исправлено? Что-нибудь ломается, когда он выделяется, скажем, на 53-й ГБ адресного пространства вашей программы? (Попробуйте выделить огромное количество, а затем динамически создавать формы, элементы управления и т. Д. - они, вероятно, будут созданы с высокими адресами.) Разделяет ли менеджер памяти? Насколько быстро перемещается и копируется память?
Предупреждения компилятора. (Это важно.) Обновите свои программы - скомпилируйте их без изменений и посмотрите, какие предупреждения / ошибки вы получаете; исправить любое; а затем исправлять ошибки, которые возникают, даже если вы не были предупреждены. С какими проблемами вы столкнулись? Должен ли компилятор предупреждать вас, но не сделал этого? Получаете ли вы предупреждения при усечении указателя при приведении к целому числу? Что насчет более сложных вопросов: если вы используете тип с плавающей точкой Single, что произойдет? Предупреждение, или он молча представлен как double? Что если вы передадите параметр методу другого размера - например, PostMessage и передадите значение 32-битного размера параметру handle - компилятор будет достаточно умен, чтобы догадаться, что если размер неправильный, ваш код может быть неправильным, даже если часто допустимо передавать меньший тип в больший параметр? При каких обстоятельствах он должен это делать? (Другое дело: что если вы передадите 64-битный указатель на 32-битный тип в методе, ожидающем указатель на 64-битный тип - безопасность типов должна громко кричать, но не так ли? Вариант использования для этого - чтение блоки из двоичного файла, что может легко вызвать проблемы с типами неправильного размера.) ... и т. д.
Предупреждения компилятора, вероятно, являются одним из наиболее полезных инструментов для людей, которые осуществляют обновление, поэтому компилятор должен выдавать как можно больше, в максимально возможном количестве ситуаций, с минимальным количеством ложных срабатываний. Помните Delphi используется широким кругом программистов - вы можете знать, что означает предупреждение, или распознавать плохой код, даже если компилятор молчит, но важно все, что поможет новичкам (или хорошим программистам, у которых плохой день).
Пользовательские элементы управления и WinAPI. Возможно, у вас есть несколько таможенных элементов управления или фрагментов кода, которые интенсивно используют API-интерфейсы Windows вместо VCL. Существуют ли какие-либо проблемы, связанные с API Windows?
Совместимость с языками. Работает ли старый код ввода-вывода файла - AssignFile и т. Д.? RTTI? Если у вас есть подпись события с типом Integer, и IDE автоматически создает обработчик событий, генерируется ли он как Integer или как целочисленный тип определенного размера, в зависимости от платформы, которая в данный момент установлена? Что если событие NativeInt, что тогда? (Я видел ошибки в генерации сигнатур метода обработчика событий, хотя только на стороне C ++.)
Различные типы приложений. Можно предположить, что программы с графическим интерфейсом хорошо протестированы. А как насчет консольных и сервисных приложений?
Создание файлов, совместимых с C ++ Builder. C ++ Builder не будет 64-разрядным в XE2, но, надеюсь, будет в XE3.Однако Delphi может создавать файлы ..hpp и .obj для кода на Паскале.Что происходит с 64-битной платформой?Можете ли вы создать эти файлы, даже если они бесполезны?Генерирует ли компилятор специфичные для C ++ предупреждения в 64-битном режиме, или он сдается и не позволяет вам это делать?В 32-битном режиме, есть ли что-нибудь, что вы можете сделать для 64-битной совместимости, которая будет генерировать предупреждение при построении заголовка C ++?
Linker. Можете ли вы связатьФайлы .lib и .obj, созданные с помощью других компиляторов?(Я бы ожидал .lib да, .obj нет.) Использует ли компоновщик COFF или OMF для 64-битной версии - они изменились? Этот поток подразумевает формат ELF.Изменился ли он и для 32-битной версии?Влияет ли это на формат DCU, будем ли мы по-прежнему получать сверхбыструю компиляцию / компоновку?
COM и 64-битные плагины. Есть ли проблемы с сортировкой?Можете ли вы создать 64-битный плагин для Explorer сейчас?
Соглашения о вызовах. Safecall должно быть единственным «соглашением о вызовах» (если safecall имеет значение ...) это все еще по-другому - это все еще работает?Указатели на функции и процедуры и замыкания (указатели на метод объекта): они работают?Как они выглядят в инспекторе отладки?Учитывая, что все соглашения о вызовах теперь одинаковы, что произойдет, если вы смешаете соглашения о вызовах в объявлении метода и указателе вызова?Есть ли какие-нибудь устаревшие вещи, которые сломаются или это прозрачно работает?Выдает ли оно теперь (ошибочное) предупреждение о несовместимости типов?
Математика с плавающей запятой. Предварительный просмотр Delphi 64 Сказал плавающийточка будет только двойной.Может ли Delphi обрабатывать long double с?Существуют ли какие-либо процедуры совместимости для обработки старого типа Real (48 бит, я думаю ??)?Генерирует ли компилятор код SSE или SSE2 или микс, и насколько он хорош?
Производительность. Это их первый переход на 64-битный компилятор;это, вероятно, будет улучшено в течение следующих нескольких выпусков.Но есть ли очевидные проблемы с производительностью, с:
компиляцией;связь;IDE Insight?
Сгенерированный код: ваши программы быстрее или медленнее?FP математика быстрее или медленнее?Работает ли inline и генерирует ли он ненужные биты верхнего / нижнего колонтитула вокруг встроенных методов?
Отладка .Это, вероятно, проще всего проверить во всем процессе тестирования всего остального, но насколько хорошо работает 64-разрядный отладчик?Есть ли у него все функциональные возможности 32-битного?Работают ли плагины визуализатора отладки IDE?Что если вы отлаживаете не-Delphi 64-битную программу или присоединяетесь к процессу, вместо того, чтобы нормально работать?
Разное Является ли сам Delphi скомпилированным как 64-битовая программа?Если нет, то почему?(Они "едят свою собачью еду"?) Код проверяет новый VCL (при условии, что предварительный просмотр идет с исходным кодом VCL.) Что они сделали, чтобы сделать VCL 32/64 совместимым?Есть ли какие-либо ошибки, или если вы уже хорошо знаете 64-битный код из других IDE, есть ли лучшие подходы, которые они могли бы использовать вместо этого?
... и т. Д.Я мог бы продолжать печатать часами, но я думаю, что это хорошее начало:)