← All posts tagged Windows

Kim
Windows x86_64 sbcl it's_work see_/12 Антон Коваленко анонсировал, что он завёл sbcl на x86-64 архитектуре. Собственно линк: siftsoft.com

Его порт явно не может работать (как минимум из-за того что в src/runtime/x86-64-assem.S не исправлено соглашение о передаче параметров, которое на win64 отличается от всех остальных x86_64 систем) и у меня не работает. Жуйкоюзер, если у тебя шестидесятичетырёхбитные окошки — можешь попробовать запустить? Если я правильно понимаю код и это не мои локальные проблемы, а он действительно не работает, то надо будет идти в рассылку со своим вариантом порта (где на данный момент GC ещё не хочет работать, но вся остальная инициализация из src/code/cold-init.lisp проходит).
Kim
Windows x86_64 sbcl Кроме указанных в предыдущем сообщении проблем (вторая и третья поправлены, первая заменена заглушкой) наткнулся на то, что соглашения о вызове функций на Windows x64 отличается от всех остальных систем архитектуры x86_64. Так в юниксах для аргументов используется соответственно последовательность мест "rdi — rsi — rdx — rcx — r8 — r9 — rest on stack", а для windows x64 "rcx — rdx — r8 — r9 — rest on stack".

Пока получается что-то вроде pastebin.com

Наверное стоить оформить окончательно удаление long из кода и, если такие изменения не придутся по нраву разработчикам sbcl, то забить на доведение кода до рабочего состояния.
Kim
Windows x86_64 sbcl Для портирования SBCL на 64-битную Windows необходимо решить три проблемы:

1. Замена SEH на VEH, для обработки ошибок. Тут можно оставить заглушку до тех пор, пока не соберется относительно рабочий SBCL.
2. Изменить схемы именования системных функций. Так функции, которые в 32-битной системе (кстати, это особенность Windows или MinGW?) соответствуют символам "_Name@number", а в 64-битной "_Name" или просто "Name" (откуда возникает эта проблема? В amd64-mingw у меня под дебианом создаются символы "_Name", а с использованием drangon.org сборки — "Name")
3. Убрать из исходников надежду на то, что система поддерживает ANSI C. Или, говоря конкретнее, исправить все места, где встречается long int или unsigned long int, подставив вместо long подходящий тип, который будет иметь размер не меньше, чем long int, int и void* на всех архитектурах.

Третий пункт требует порядка 500 правок. К сожалению после того как я внёс эти правки, а также поправил правила именования и организовал заглушку на исключениях, получившийся runtime не в состоянии правильно разобрать сгенерированный в результате кросскомпиляции sbcl.core файл. Так что, судя по всему, до сих пор в коде есть места, в которых размеры переменных не сходятся.