Netspirit, решил немного покопаться в hiMathParse дабы запустить в x64 но результат не порадовал, пример приведённый выше не совсем корректный, компиляции удалось добиться только с директивами как в следующем примере
code_32818.txt
но результат вычислений не соответствует реальному. Кроме того вставка директив в hiMathParse приводит к синтаксическим ошибкам.
наверное это лучший вариант.

Netspirit, убрал ASM вставки из hiMathParse заменив на тождественные из набора базовых функций, компиляция на x64 прошла успешно а вот результат вычислений для плавающих типов поплыл . Ниже правленый hiMathParse.
http://forum.hiasm.com//getfile/32841

Сейчас не могу проверить твой вариант.
Там в FPC есть стандартные функции в Math: FPC2srcobjpasmath.pp
Ещё, если кто разбирается, можно эти функции переписать на иснтрукциях SSE вместо MMX.

Netspirit, в архиве маленький пример который показует что проблема глубже чем убрать ASM вставки из hiMathParse.

Проблема не в неправильных вычислениях, а в неправильном выводе результатов - в x64 неправильно работает функция KOL.Extended2Str.
code_32846.txt
------------ Дoбавленo в 21.30:
Переписал Extended2Str на аналогичную из FPC. Поправил MathParse.

Распаковать архив с заменой в папку HiAsm.
После распаковки выполнить HiAsmcompilerFPC2src\_make_x64.bat

Netspirit, внесённые изменения заработали без ошибок. Далее три доработаных компонента совместимых с x64.
ps: старый fpc как старая мебель и место занимает и выкинуть жалко , куда ему тягаться с новым fpc x32.
ps2: Netspirit, зпустить бы ещё панель и редакторы текста

Попробую

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

А для более удобного и быстрого исследования кода, прикрутил пакет к среде Lazarus, жаль только, пока не получилось произвести компиляцию из среды Лазаруса

Из Лазаруса по-умолчанию не скомпилируется - нужно внести некоторые поправки в модуль Windows и пересобрать. Или попробовать взять этот модуль отсюда, но придется пересобрать другие зависимые модули.
Также может быть лучшим вариантом натравить Лазарус на использование только модулей в папке compilerFPC2unitsXX. Для этого нужно поместить в папку с проектом файл fpc.cfg с соответствующими параметрами или настроить в свойствах проекта. Не знаю, правда, будет ли работать отладчик.

Netspirit, это я уже понял, но мне как то всё равно, откуда запускать, задача была получить больше информации, в случае критической ошибки
Вот кстати, чего я добился:
Это кстати схема DelphiExampleDrawAll_Img_Draw_&_Print.sha
Как оказалось, отладчик подключается на раз-два, а вот вывести информацию о строках с ошибками, уже не так просто.
В качестве решения пришлось подключить exeinfo.pp, lineinfo и зависимые модули, из исходников fpc, что дало возможность получать расширенную информацию об ошибке
------------ Дoбавленo в 04.24:
Итак, пока не заснул, вот архив с добавлением расширенной информации об ошибках.
hiasm_fpc_debug.zip

Последовательность действий:
1) Распаковать в каталог с HiAsm.
2) Добавить 2 новых компилятора, запустив: HiAsmcompilerFPC2Install_debug.his
2.1) Или добавив вручную:
Остальные параметры соответствуют профилям FPCx32 и соответственно FPCx64

3) Собрать модули, запустив HiAsmcompilerFPC2src\_make_x32_debug.bat и/или HiAsmcompilerFPC2src\_make_x64_debug.bat.
4) Если ничего не упустил (сонный), теперь при компиляции схемы с одним из новых профилей компиляторов, при возникновении ошибок, мы получим расширенную информацию.

Как то так
------------ Дoбавленo в 13.19:
Так, теперь бы подключить к пакету ещё и кодовою базу Lazarusa, но как я понял, это будет не так уж и просто

CriDos, никак не удалось получить сообщения об ошибках с названиями файлов и процедур как у тебя.
Вот как я для себя сделал. Пробовал даже твой вариант без изменений. Посмотри, может что не так.
Или программу нужно запускать под отладчиком?

Нет, модули exeinfo,lineinfo как раз и нужны, для того что бы добавить информацию об исходном коде (отладочные символы), которые попадут в компилируемый файл и затем отобразятся вместе с остальной информацией в эксепшенах.

Netspirit, только что проверил, вроде всё работает.
Если ты проверял на примере "DelphiExampleDrawAll_Img_Draw_&_Print.sha", то нужно сначало исправить тип аргументов методов в файле "hiIntegerArray.pas" с cardinal на NativeInt, и потом скомпилировать схему 64 битным компилятором (FPCx64_Debug), т.к. с 32 битным проблем не возникает в данной схеме.

На всякий случай, архив с интегрированным дебагом:
HiAsm_AltBuild_fpc.7z
После извлечения, необходимо будет запустить _make_x32_debug.bat и/или _make_x64_debug.bat.

Да, на этой схеме у меня тоже заработало. В некоторых случаях прием не срабатывает: на выходных целый день искал ошибки с помощью расстановки MessageBox'ов.

Netspirit, ну, вообще, если взглянуть на эту мешанину ASM, fpc старого синтаксиса, delphi старого синтаксиса, delphi нового синтаксиса и новый компилятор FPC, я удивился, что данный способ вообще заработал)
В общем, к-во граблей использованных в пакете Delphi и библиотеке KOL, просто зашкаливает, и первое что пришло в голову: "блин, легче переписать пакет ", т.к. в дальнейшем на отлов ошибок (особенно логических), может уйти куча времени...

В итоге, у нас имеется: Куча потенциальных ошибок в оригинальном пакете + грабли под старые компиляторы, и теперь ещё в придачу, куча ошибок в новом + переработанные грабли под новый компилятор и x64 битку + ещё больше потенциально новых ошибок, и всё это приправлено новым KOL с исправленными ошибками и с возможными новыми ошибками
Отсутствие вспомогательных современных инструментов, так же в разы усиливает "эффект жести"...

p.s. Это так, размышления в слух

Да, я тоже считаю, что KOL написана в стиле "баг на костылях, граблями подгоняемый". Но единственная проблема в том, что автор тестирует её только на Delphi без какой-либо оглядки на FPC, при этом не гнушаясь использовать "грязные хаки" по особенностях конкретного компилятора.
Но не вижу никаких принципиальных трудностей, не позволяющих довести связку новых FPC+KOL 32/64 до юзабельного состояния.

Из недавно обнаруженного: в KOL отключено выравнивание записей с комментарием "align off, otherwise code is not good". Необходимость в этом вероятно возникла из-за использования относительных смещений в каких-то функциях. Тогда как выравнивание наоборот призвано ускорить доступ к полям записей, а в x64 ещё и Windows API требуют записей, выровненных по 8 байт. Приходится объявленные в KOL записи искусственно "выравнивать" дополнительными полями. Проверю, будет ли много ошибок, если выравнивание таки включить.